Re: File Permission change
On Wed, 7 Jul 2021 12:28:35 -0500, Vinoth wrote abour File Permission change: > we are in situation to change the owner for the path /SYSG/prod/cft36/, > we have tons of files/directories residing on this path and i tried to > change using a batch job and only the filepath specified on the job gets > change and rest remains the old owner name and this is stopping me on the > upgrade. chown -R : /SYSG/prod/cft36 You might need to be suoeruser (i.e. root) to do this. The key is the -R option, as it recurses through the subdirectories. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X
On Thu, 6 Aug 2020 21:47:26 +, Dymoke-bradshaw, Lennie wrote abour Re: Copy DSNTYPE=BASIC to DSNTYPE=EXTREQ with LRECL=X: > Matthew, > > Each of those will ensure the output data set is extended format. That is not > the issue. > The issue is what program do I use to copy the data when LRECL=X. Have you tried SORT FIELDS=COPY or the like? DF/SORT or Syncsort. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Enterprise COBOL 6.3 and IBM Programmer Tools
On Thu, 9 Jan 2020 17:23:51 +1100, Attila Fogarasi wrote abour Re: Enterprise COBOL 6.3 and IBM Programmer Tools: > There is a 64-bit ODBC driver so Db2 does provide a 64 bit API today, just > not for embedded SQL :) The ODBC driver runs on the client machine, not the host. The host interface is almost certainly accessing DB2 in 31-bit AMODE. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM record length 0
On Sat, 28 Dec 2019 00:31:57 +, Frank Swarbrick wrote abour Re: VSAM record length 0: > I understand that. I thought the CRLF would be "in the clear", which > would make the record (in the sequential file, sent from an ASCII > system) 0 length. But that was an invalid assumption. The "field" > that includes the CRLF is base64 encoded rather than containing an > actual CRLF. Base64 swallows everything in the input stream, without assuming any record or field delimiters. It is treated as a pure byte stream. You need to decode it the same way and then find any delimiters in the decoded stream. All the encoded characters are from the 6-bit collating sequence defined by Base64, but widened to ASCII or EBCDIC. > I'm not sure how INSPECT...REPLACING can be used since there is not a > 1-byte to 1-byte correspondence... You'll need to use at least 2 INSPECT verbs and then meld the pieces. The issue is to take 3 bytes and convert it to 4 to encode, and 4 bytes to 3 to decode. I implemented Base64 in PL/I about 25 years ago, using the TRANSLATE() builtin function. That largely corresponds to INSPECT ... REPLACING in COBOL. I think I still have that code on a tape cartridge, but I don't think the tape drive I used to back it up still works. ... :-( -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM record length 0
On Fri, 27 Dec 2019 23:46:12 +, Frank Swarbrick wrote abour Re: VSAM record length 0: > It turns out I was not quite on the right track. The 'record format' > of the file does allow for a CRLF sequence embedded in it, but it does > it by Base64 encoding the data, rather than including an "additional" > CRLF as I had assumed. A CR/LF pair is normally just a line terminator, especially when the record is Base64 encoded. Normally you just drop the line terminator. If you plan on keeping the data encoded as Base64, there should be no zero-length records. Since Base64 data are a byte stream, the only record boundaries are going to be by some kind of convention: CR/LF on Microsoft platforms; CR on Apple; and LF on UNIX. > So now the question is, does z/OS have a Base64 decoding routine? > I see that Enterprise PL/I has one, but I don't see anything for > Enterprise COBOL. I can probably call a function from the C Runtime > if there is one. (And no, I am probably not going to call a Java > routine...) You can implement Base64 encoding/decoding in COBOL, typically by using one or two INSPECT ... REPLACING verbs. Take a look at RFC 3548 to see the standard algorithm: <https://tools.ietf.org/html/rfc3548.html> HTH. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSAM record length 0
On Fri, 27 Dec 2019 22:55:35 +, Frank Swarbrick wrote abour VSAM record length 0: > So I am trying to copy sequential file to a VSAM ESDS. One of the > lines in the source file has a record length of zero. Apparently > VSAM does not support zero-length records? Can this be true? It is true. The Record Descriptor Field at the high address end of the Control Interval cannot be zero. > This blank line has "meaning". What are my options? Append a CRC (or similar checksum) to each record -- you can pretend it's for data integrity checking -- and for the zero-length record just write the CRC. Just remember to strip the CRC when you read the dataset back again. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but not without?
On Wed, 18 Dec 2019 22:28:12 +, Farley, Peter X23353 wrote abour SYNCSORT question: Why error INCOMPATIBLE LRECL usint TRAILER1 but not without?: [snip] > //SORTOUT DD DISP=(,CATLG,CATLG), > // DSN=output-VB-file, > // UNIT=SYSDA,SPACE=(CYL,(010,010),RLSE), > // DSORG=PS,RECFM=VBA,LRECL=045,BLKSIZE=0 Your SORTOUT has a 4-byte RDW, an ASA control character and up to 40 print positions in any given logical record. [snip] > TRAILER1=(6:C'TOTALS',4X,TOT=(5,11,ZD),23X), 6 + 4 + 11 + 23 = 44, which is > 40. I would ditch the 23 trailing spaces. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Adding a PARM to a PROCSTEP where no PARM is coded
On Tue, 17 Dec 2019 22:42:45 +, Farley, Peter X23353 wrote abour Adding a PARM to a PROCSTEP where no PARM is coded: > I thought I know this stuff, but my employer's z/OS V2.2 system is saying I > don't. > > I have a simple one-step PROC which executes a COBOL program but has no > keyword parameters on the EXEC statement, like this: > > //MYPROC PROC OUT=* > //MYPGM EXEC PGM=MYPGM > //SYSOUT DD SYSOUT= > // PEND > > MYPGM is compiled with COBOL V5.2 and has a LINKAGE SECTION like this: > >LINKAGE SECTION. >01 PARM-FIELDS. >05 PARM-LENGTH PIC S9(04) COMP. >05 PARM-AREA PIC X(25). > Did your PROCEDURE DIVISION statement include USING PARM-FIELDS ? -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@gmail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VTOC reading
On Thu, 13 Jun 2019 11:44:24 -0400, Bill Ogden wrote abour VTOC reading: > My old memory is failing in too many areas. Long ago, I seem to recall, > there was an easy way to read a VTOC with simple JCL using a "magic" > DSNAME - obviously not 040404... for JCL, but some other name. Is my > memory correct? What is the DSNAME? While playing with google I cannot > find anything, but I might be using the wrong search words. DSN=FORMAT4.DSCB -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Using DFSORT to generate data
On Thu, 28 Mar 2019 14:14:46 -0500, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote abour Re: Using DFSORT to generate data: > On Thu, 28 Mar 2019 11:38:24 -0700, Sri h Kolusu wrote: > >>> I'm astonished; I'd expect data bases to log times of transactions. Or is >>> that left the responsibility of the UI/API? >> >> When I say DB2 gives a static timestamp is when you are trying to get >> EXISTING records from a DB2 table and append a time stamp. ... >> > OK. I RTFM. The term it uses in a few places is "time of the run". I'm > happy that means the time of the SELECT rather than time of the FETCH. The CURRENT TIMESTAMP special register is evaluated at the time of the first query in a transaction; likewise CURRENT TIME and CURRENT DATE. This is not necessarily the same as the time of the SELECT. The special registers get re-evaluated after any subsequent COMMIT or ROLLBACK the terminates a transaction, when the next transaction begins. > May I assume, since neither you nor Bernd said otherwise, that insertion > of a row will use the instantaneous timestamp? No, the INSERT will use the special register, as evaluated at the start of its transaction. This is why TIMESTAMP data attributes are not ideal "tie breakers" for key collisions: there are other ways to do that. > And disappointed, that the format has a granularity of at best µsec, > sacrificing the uniqueness of the (E)TOD clock. Not an issue > unless/until processors are fast enough to perform more than one > transaction in that time. The format was decided decades ago by a committee. The purpose of TIMESTAMP is just its face value: to provide a temporal log of when a database event occurred. It is a measure of external times, rather than of the internal clock of the CPU. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VM (Subject clip volume with JCL)
On Wed, 14 Nov 2018 14:49:42 -0500, Tony Harminc (t...@harminc.net) wrote about "Re: VM (Subject clip volume with JCL)" (in ): > On 14 November 2018 at 14:34, Paul Gilmartin > <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > >> And, all, please trim the superfluous footers, disclaimers, etc. >> (It's the malign consequence of top-posting.) > > Better yet, don't top-post! Selectively quote, insert your comments > where they belong, and trim with care. +1000 -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Why are sophisticated system-level coding examples not available? [was: RE: Recommended method for accessing secondary access spaces]
On Mon, 12 Nov 2018 18:13:30 +, Farley, Peter X23353 (peter.far...@broadridge.com) wrote about "Why are sophisticated system-level coding examples not available? [was: RE: Recommended method for accessing secondary access spaces]" (in ): > Not jumping on Ed Jaffe or Peter Relson or any of the other thoughtful > and helpful responders in this email chain, but it still rankles me > that there are no good examples anywhere (not at IBM and not at CBT) > for programmers to review that show exactly how to set up and use "SRB > to the other address space and PC-ss back to the requesting address > space" or any similarly sophisticated system-level application coding > technique. > > Why is system-level application coding made an obscure mystery to which > only IBM and (some) ISV's have access? Good examples that show how to > "do the right thing" would avoid an awful lot of dangerous experimentation. > "Security through obscurity" is, I think all here would agree. NOT a good > thing. I can offer an opinion based on my years as a developer for various ISVs. Each ISV considers its more sophisticated code to be some kind of magic joojoo that it wants to keep private as a competitive advantage. The curious part is, most developers have worked for a variety of ISVs and have spread the magic as they went, so the slick code tended to be fairly similar in all the ISV companies. I think most of the low-level techniques were derived from code seen on the IBM-supplied microfiche (remember that?) that arrived with MVS installation media. It would benefit the mainframe industry if microfiche (or a more modern medium) were reinstated. There are no longer any other platform-level vendors in mainframes any more, so nobody is going to bootleg z/OS as their own operating system. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL 64bit
On Thu, 18 Oct 2018 15:01:33 -0400, Steve Thompson (ste...@copper.net) wrote about "Re: COBOL 64bit" (in ): [snip] > Assume that this data set is a VSAM KSDS. And assume that we do random > access of the records, and that those records contain pricing and rules > for same. Why not use a big LSR pool for that dataset? That should speed up random processing a treat and not use anywhere near as much memory as a full dataset load. The BLSR subsystem is just the ticket for situations like that. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there an API to a "storage dump line" formatting routine?
On Fri, 21 Sep 2018 15:34:29 -0400, Tom Conley (pinnc...@rochester.rr.com) wrote about "Re: Is there an API to a "storage dump line" formatting routine?" (in <21fc8189-7c87-a2a3-31ea-3b5acb769...@rochester.rr.com>): > On 9/21/2018 2:15 PM, Farley, Peter x23353 wrote: [snip]>> Standard system storage dumps (SYSUDUMP, SNAP/SNAPX, etc.) format >> storage displays like this in a 121-character line: >> >> 36B219C0 >> ** [snip] > You could call IPCS to display the storage you want. Under the covers, IPCS is really just AMDPRDMP. There is likely a subroutine inside AMDPRDMP that formats the print line. Whether that subroutine is callable from another program is an open question: it might have an external symbol in the link map of AMDPRDMP that one can alias, but then again it might not. I am not sure what Peter's original message was about, in terms of objective. I assume he wants to be able to format a dump of storage from inside a program. If such a program is written in PL/I, one can use the HEXIMAGE() and TRANSLATE() built-in functions to build the hexadecimal digits and dots/characters, with the the asterisks and spaces easily inserted. There is even a PLIDUMP() built-in subroutine that can dump areas directly, just like a SNAP macro. If for some reason one cannot use PL/I, that is not of much use. Since PL/I uses LE for much of its run-time support, there is likely a CEEDUMP() subroutine one can use from other languages: RTFM! -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSE splits from Microfocus
On Tue, 3 Jul 2018 21:02:41 -0400, Phil Smith Iii (li...@akphs.com) wrote about "Re: SUSE splits from Microfocus" (in <00a201d41332$b65763a0$23062ae0$@akphs.com>): > David W Noon wrote: [snip] >> A lot of the old EDS mainframers were made redundant because HP felt the >> mainframe was dead. The mainframe now helps to keep HPE alive. > > How's that? HPE NonStop isn't a mainframe. x86 servers aren't mainframes. I > don't understand. Last I heard, HPE was still running some big iron to support "legacy" applications. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUSE splits from Microfocus
On Tue, 3 Jul 2018 17:56:08 -0400, Phil Smith Iii (li...@akphs.com) wrote about "Re: SUSE splits from Microfocus" (in <007801d41318$a68872d0$f3995870$@akphs.com>): > So some folks went: HP==>HPE==>DXC; some went HP==>HPE==>Micro Focus; some > went just HP==>HPE; and some even stayed as HP the whole time. Some of my old work-mates went: EDS==>HP==>out-the-door. A lot of the old EDS mainframers were made redundant because HP felt the mainframe was dead. The mainframe now helps to keep HPE alive. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 16:43:02 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RECFM=VBS,LRECL=X" (in <1556897214786710.wa.paulgboulderaim@listserv.ua.edu>): > On Wed, 2 May 2018 22:30:00 +0100, David W Noon wrote: [snip] >> If you are using QSAM, the access method should do it. With RECFM=VBS >> you are required to use move mode processing and QSAM should do the >> buffer management, including reassembling each logical record as it move >> the data to you work area. >> > Suppose there is no guarantee that every logical record fit in available > virtual memory? How do you process such a logical record in a finite address space? The only way I can think of is to segment the record and process it piecewise. That would require BSAM, since the buffer pool will fit into memory, and the record segments will be limited in size to fit into a buffer. You then have an issue of related fields not being in the same segment or not being in segments close enough to have the related fields accessed concurrently. I would then feel that the data stream design is flawed. I would want it normalized, when possible. The problem with that is that many "small platform" people know little or nothing about normal forms. [Indeed, it is mainly DB2 and IMS people who understand it on the mainframe.] The problem remains if the record layout is already in at least 1NF. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RECFM=VBS,LRECL=X
On Wed, 2 May 2018 14:39:57 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RECFM=VBS,LRECL=X" (in <7993773034062407.wa.paulgboulderaim@listserv.ua.edu>): > On Wed, 2 May 2018 13:23:21 -0500, Kirk Wolf wrote: > >> Does anyone use this with your z/OS data sets? >> > I've experimented with it. I was semi-pleased to discover that while > BPXWYN rejects LRECL(X) as a syntax error it accepts LRECL(32768) instead. > > I don't recall whether Rexx reassembles spanned records or whether I > needed to override with RECFM(U) and process the streams myself. If you are using QSAM, the access method should do it. With RECFM=VBS you are required to use move mode processing and QSAM should do the buffer management, including reassembling each logical record as it move the data to you work area. AFAIAA, REXX EXECIO uses QSAM. I have processed VBS records using BSAM. It is a bit of a chore ensuring that the spanning indicator bits in the RDWs are set correctly. > I don't know which utilities are sensitive to which BFTEK values. I have not seen BFTEK do anything particularly useful. > RECFM=VBS,LRECL=X would seem natural for processing UNIX files. UNIX files for input? No, these lack BDW and RDW fields and cannot be processed by QSAM as anything other than RECFM=U (or perhaps RECFM=F[B]). If they are text files, you still need to scan the buffer to find the '\n' character that terminates each text record. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEFA107I when pointing to dataset alias
On Mon, 30 Apr 2018 16:34:43 +, Sankaranarayanan, Vignesh (vignesh.v.sankaranaraya...@marks-and-spencer.com) wrote about "IEFA107I when pointing to dataset alias" (in <db3pr02mb038035cc3845ab536c629cf7da...@db3pr02mb0380.eurprd02.prod.outlook.com>): > Let's say I have A.DATA.SET in APF and LNK. > I then create B.DATA.SET as an alias to A.DATA.SET Are the A and B HLQs aliased to the same catalogue? The alias will be in the catalogue for A, and if DSN lookups for B.* don't go to the same catalogue then the lookup for your alias will not be found. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUBSYS= ?
On Thu, 9 Nov 2017 23:39:28 +, Farley, Peter X23353 (peter.far...@broadridge.com) wrote about "Re: SUBSYS= ?" (in <0cfc6aa1608c478fbfa1133fa3491...@clipswexmaa4.bsg.ad.adp.com>): > You are totally correct about that. I forgot for a minute > that when using SUBSYS=BLSR the actual file name is moved off > to a separate DD, and I should have remembered that because I > have coded an awful lot of them. > > Thanks for reminding me. > > So I guess that restriction may still be real: Don't use > SUBSYS and DSN=(SMS managed DSN) on the same DD statement. Just to add to this melee: when using an RLS subsystem the SUBSYS= is coded on the DD statement, thus: //CLUSTER DD DSN=PROD.CLUSTER,SUBSYS='RCIC',DISP=SHR where RCIC is the subsystem name of a CICS FOR that has been configured for RLS. This is how it is coded even when the cluster is SMS-managed. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SUBSYS= ?
On Tue, 7 Nov 2017 00:07:13 +, Jesse 1 Robinson (jesse1.robin...@sce.com) wrote about "Re: SUBSYS= ?" (in <cy1pr0101mb08589f91be8150c372714704bf...@cy1pr0101mb0858.prod.exchangelabs.com>): > My comment about deprecation was limited to the SUBSYS= keyword. I saw > from other replies that Panvalet and Librarian use the keyword. More than that, the SUBSYS keyword is used for RLS and BLSR processing of VSAM clusters -- and those are IBM subsystems. Deprecating that would cause wholesale breakage at sites that do a lot of VSAM processing. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What cryptographic algorithm is not supported?
On Mon, 6 Nov 2017 14:32:01 -0800, Charles Mills (charl...@mcn.org) wrote about "What cryptographic algorithm is not supported?" (in <210a01d3574f$11063a10$3312ae30$@mcn.org>): > I am trying to load a certificate and key into a FIPS-140 GSK database. I am > getting Status 0x03353003 - Cryptographic algorithm is not supported. How > would I know exactly what algorithm it is complaining about? Here's an > extract from the certificate and key: You have 2 lines that mention algorithms: > Signature Algorithm: sha512WithRSAEncryption > Public Key Algorithm: rsaEncryption (There is actually a 3rd one, but it is the same as the first.) Now, SHA512 is a hashing algorithm, so that leaves RSA as your crypto algorithm. I don't know why RSA would be unsupported, as it has been around since the late 1970's. I can only infer that it has been dropped. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: too true: Vulture Central on "the next big thing".
On Fri, 20 Oct 2017 18:30:25 +, Allan Staller (allan.stal...@hcl.com) wrote about "Re: too true: Vulture Central on "the next big thing"." (in <sg2pr04mb0959a12157a5c714e7bf8e47e3...@sg2pr04mb0959.apcprd04.prod.outlook.com>): > My understanding (albeit limited) is that O-O is modular programming with the > concept of "inheritance" added. There is considerably more than that. As a moron's guide to Object Oriented Programming (OOP) here is a simple, layered approach: The first part is encapsulation. This consists of laying out a data structure, called a class, that will be instantiated whenever it is needed. This data structure then has methods (an up-market term for subroutines and functions) associated with it, but most of these methods can only be invoked using an instance of the class. Thus, the methods are encapsulated by the class. The second part is polymorphism. This allows a single method name to be used with different semantics, based on the class through which it is invoked and its argument signature. This is identical to the PL/I GENERIC declaration, except the rules for monomorphic selection on a polymorphic name have to be coded explicitly in PL/I but are inferred by the compiler in more modern languages. The third part is inheritance. This permits new classes to be declared based on existing classes, with the new classes inheriting the data items in the structure and the methods encapsulated in the earlier classes. These are called subclasses. The methods can be overridden in the subclasses if necessary. Additional data items can be added to the structure too. Actually laying out a class requires a great deal of analysis. This is why people who can b.s. their way into senior analyst positions rattle on about Object Oriented Design (OOD) as if it were some kind of magic. There is no moron's guide to OOD, as it can be exceedingly complex. > I am not sure if SP caused modular or vice-versa. Modular programming came in with FORTRAN II in the late 1950s, when it started allowing FUNCTION and SUBROUTINE definitions. This is long before Structured Programming. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN from CLIST
On Wed, 18 Oct 2017 17:52:16 +, Pinion, Richard W. (rpin...@firsttennessee.com) wrote about "Re: BPXWDYN from CLIST" (in <9100e2e5ca18c64885a04cd21a78be9b27ff7...@feprexmbx03.ftbco.ftn.com>): > I want to know what data set is allocated to a DDNAME, and the data set is on > tape so LISTDSI won't work. In that case you want to examine the TIOT/SIOT/DSABQ. At one of my previous employers, we had a CP called dtiot that would do just that. One could its output and extract the DD one wanted. Such CP's were ubiquitous back in the 1980s. Perhaps your site has one. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPXWDYN from CLIST
On Wed, 18 Oct 2017 17:04:14 +, Pinion, Richard W. (rpin...@firsttennessee.com) wrote about "BPXWDYN from CLIST" (in <9100e2e5ca18c64885a04cd21a78be9b27ff7...@feprexmbx03.ftbco.ftn.com>): > Does anybody have an example of calling BPXWDYN from > a CLIST? And no I can't use REXX. Won't the ALLOC command work? -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the "z/OS V2R3 Elements and Features" web site?
On Tue, 17 Oct 2017 19:48:54 +, Pew, Curtis G (curtis@austin.utexas.edu) wrote about "Re: Where is the "z/OS V2R3 Elements and Features" web site?" (in <ce19c403-d209-46a5-a362-e93477365...@austin.utexas.edu>): [snip] > At least three of the documents in the z/OS 2.3 collection have blank > titles in their PDF information. The problem is not developing a script > to create links from the information, the problem is missing information. More than that, some of the IBM documents have a Title: field with the same name as the PDF filename or basename. I'm not sure what type of documentation software IBM uses to prepare these, but I guess it isn't fussy about the Title: not matching the text on the title page. I expect it's an Adobe product for Windows (Distiller?). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where is the "z/OS V2R3 Elements and Features" web site?
On Mon, 16 Oct 2017 20:17:01 +, Pew, Curtis G
(curtis@austin.utexas.edu) wrote about "Re: Where is the "z/OS V2R3
Elements and Features" web site?" (in
<bb96fb07-0d7a-4af6-8bae-ceaec1909...@austin.utexas.edu>):
> On Oct 16, 2017, at 1:39 PM, John McKown <john.archie.mck...@gmail.com> wrote:
>>
[snip]
>> for i in *.pdf ; do pdfinfo "${i}" | ln -s "${i}" "$(awk '/^Title: / {print
>> substr($0,17);} | sed -r 's/ *.*? *//')" ; done
One can avoid the use of sed here. Moreover, we need to do more
manipulation of the generated filename for the symlink.
> Yes, please. I tried doing something like this once, but the PDF
> information sections are inconsistent or incomplete. Everything’s
> easier to manage when you have consistent, reliable metadata.
I have attached a shell script for zsh that might do what you want. It
is another "pretend text" attachment, so rename it with the ,txt suffix
removed. Also remember to "chmod +x" to make it executable.
Note also that this script will probably not work under Windows, even if
you have zsh installed as a shell. This is because it translates the
forward slashes IBM uses for z/OS, OS/390, OS/400, PL/I, etc. into
backward slashes, because UNIX filesystem drivers use the forward slash
as a directory separator.
I have released it under the Berkeley License, so it is fully open
source. Use at your own risk.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
#!/bin/zsh
# Script to scan PDF documents and add a symlink to those whose
# filename differs from their title fields.
# Copyright (C) 2017, David W Noon. All rights reserved.
# This code is released under the Berkeley License.
# Set default values.
DOC_DIR="."
let PRETEND_MODE=0
let VERBOSE_MODE=0
# Parse the command line.
while getopts 'pd:hv' OPTNAME
do
case "$OPTNAME" in
p)
let PRETEND_MODE=1
;;
d)
DOC_DIR="$OPTARG"
;;
h)
echo 'Usage:'
echo "\tPDF_symlinks.zsh -h -p -d "
echo ''
echo 'Where:'
echo "\t-p\t\tPretend mode."
echo "\t-d \tDirectory to scan. Default: current
directory."
echo "\t-h\t\tThis help text."
exit 0
;;
v)
let VERBOSE_MODE=1
;;
*)
echo "Invalid option $OPTNAME"
exit 12
esac
done
# Change directory if it's not current.
[[ "$DOC_DIR" == "." ]] || pushd "$DOC_DIR"
# Loop through all plain files ending in .pdf
for fn in *.pdf(N.)
do
# Extract the Title: field, massage to fit UNIX filename conventions.
sn=$(pdfinfo "${fn}" | gawk '/^Title:/ { s=$2; for(n=3;n<=NF;++n)
s=s"_"$n; gsub("/","\\",s); print s".pdf"; }')
if [[ -e "$sn" ]]; then
# Skip if name already exists.
[[ $VERBOSE_MODE -eq 1 ]] && echo "$sn already exists."
elif [[ "$sn" != "$fn" ]]; then
if [[ $PRETEND_MODE -eq 0 ]]; then
# Hit the tit!
ln -s "$fn" "$sn"
[[ $? -eq 0 && $VERBOSE_MODE -eq 1 ]] && echo "Symlink
$sn was created for $fn"
else
echo "Symlink $sn would be added to document $fn"
fi
fi
done
# Revert directory if we changed.
[[ "$DOC_DIR" == "." ]] || popd
exit 0
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ShopZ order response
On Fri, 13 Oct 2017 20:46:36 -0400, Tony Harminc (t...@harminc.net) wrote about "Re: ShopZ order response" (in <caarmm9s8ygkewkfedrrdtaz+81e28_ej2uolygc24c0jv2b...@mail.gmail.com>): > On 13 October 2017 at 18:47, Phil Smith III <li...@akphs.com> wrote: > >> Anyone know if Sterling Forest still has 3420s? Last time I was there >> (2004?) they did, and even a 7-track drive IIRC. > > Also in 2004 I was surprised to see a short string of 3420 drives, all > powered up and lights on, at one of our UK banking customers. I asked, > and it seems they were used only for data exchange. A nightly courier > would arrive from each of the other big banks with tapes, and be > dispatched with the ones from this bank. I had a vision, perhaps not > inaccurate, of each bank having such a dusty set of drives used only > for the same purpose. > > Maybe someone at a UK bank can tell us if that scheme survives today... I can't vouch for today, but the use of 9-track, reel-to-reel tapes was the standard back in the late 1990's. >From 1996 to 1999 I was working at Lloyd's Bank in London. I was working in a section called Autoclearings and our batch jobs wrote and read these tapes. The Bank of England ran a clearing house through which all financial transfers were made between clearing banks. The concrete bunker was in Uxbridge. All the clearing banks would write their pending transactions to 9-track tape (with ANSI labels and RECFM=DB ASCII records). These tapes would then be put into an armoured car and sent off to Uxbridge. Tapes containing completed transactions would be sent back to the banks so they could reconcile their accounts. In 1998 the Bank of England announced that they had a new system called High Speed Transfer (HST). This consisted of custom terminals with hardware cryptography connected to leased lines ... that went to Uxbridge. The data transmissions were made up of ANSI format HDR1 and HDR2 records, a stream of ASCII data records in RECFM=DB format, followed by ANSI format TLR1 and TLR2 records. This was not warmly received by the clearing banks as state-of-the-art technology. I find it a little surprising that reel-to-reel tape was still being used in 2004 but, given that the HST alternative was really no better, I guess we should not be really surprised. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sort Question
On Mon, 2 Oct 2017 13:02:24 -0500, Elardus Engelbrecht (elardus.engelbre...@sita.co.za) wrote about "Re: Sort Question" (in <4916708819685726.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>): [snip] > AFAIK, COBOL has its own internal SORT functions, It does not. Both PL/I and COBOL use the SORT or ICEMAN module from the linklist for their sort interfaces. > but if I want to sort something big or complex, I would terminate my > COBOL program, let sort it with DFSORT or SyncSort and do same or > other COBOL program to process the sorted data. > > If it is not too big or complex to sort, I can let COBOL call DFSORT > and wait for sorted data to come back. Unless your COBOL code is huge, it makes little difference to the performance of the sort. Just use the SORT verb in COBOL or the PLISRTx() subroutines in PL/I; they will perform just the same as a separate sort step. You need to remember to set the appropriate memory parameters in PLSIRTx() or set the COBOL special registers so that the sort can use as much memory as it needs. These compiler language interfaces have all the facilities of DF/SORT available, including the SORTPARM DD card stream. >> Does DFSORT rely on QSAM or on idiosyncratic EXCP? I'd expect > that in the era of oscillating merge it relied on EXCP. > > AFAIK, DFSORT has its own OCO access method(s) just like RACF has > its own OCO way to access the RACF database. DF/SORT has used EXCP since it was called SORT/360. Note that if SORTIN or SORTOUT is a VSAM cluster, it will use normal VSAM for reading or writing, but SORTWKxx spill files are accessed by raw channel programs (at least when the default BLOCKSET algorithm is used). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Steplib and z/OS 2.3?
On Fri, 22 Sep 2017 15:43:18 -0500, Walt Farrell (walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?" (in <1942473900671448.wa.walt.farrellgmail@listserv.ua.edu>): > On Fri, 22 Sep 2017 20:53:10 +0100, David W Noon > <david.w.n...@googlemail.com> wrote: > >> It is up to the site's programmers to ensure that the load libraries in >> use in a job step are mutually compatible. > > Unfortunately, the site's programmers are not in control of the libraries > used in a jobstep. The creator of the JCL has that control, or in the case of > something like a dynamic STEPLIB command, the TSO user who runs the command > has it. When I was a lad, the JCL was written by programmers. I certainly had to write the JCL for my programs to run; sometimes I even had to punch the cards myself. The use of dynamic STEPLIB is something of a corner case in program execution. I'm not suggesting that an ALLOC command, SVC 99 or IKJDAIR should allow STEPLIB/JOBLIB as a target. It should be managed by a well controlled facility that is custom built for this and with associated security rules. As part of this, if JSCBAUTH is already set, the dynamic STEPLIB should also be checked for presence in the current APF list.-- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Dynamic Steplib and z/OS 2.3?
On Fri, 22 Sep 2017 13:14:52 -0500, Walt Farrell (walt.farr...@gmail.com) wrote about "Re: Dynamic Steplib and z/OS 2.3?" (in <4974758334821366.wa.walt.farrellgmail@listserv.ua.edu>): > On Fri, 22 Sep 2017 10:40:59 -0500, Paul Gilmartin <paulgboul...@aim.com> > wrote: > >> Dynamic STEPLIB has been discussed in these fora so often that I suspect >> it's the subject of numerous RFEs. I suspect there are technical reasons >> that IBM has not rushed to provide the function. Is the design of OS/360 >> such that any dynamic STEPLIB would be incomplete or have unintended >> consequences? > > Any dynamic STEPLIB functionality introduces potential System Integrity> > exposures, because some parts (modules) of a program may have been loaded> from one library and others from a different, incompatible library. Such an exposure can just as easily occur from a static concatenation for STEPLIB/JOBLIB, so allowing dynamic allocation is not a significant increase in such exposure. It is up to the site's programmers to ensure that the load libraries in use in a job step are mutually compatible. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
D-flat (was: LPAR to LPAR access
On Wed, 20 Sep 2017 19:56:25 +0200, Peter Hunkeler (p...@gmx.ch) wrote about "LPAR to LPAR access" (in <ez-819528767.1353907...@gmx.ch>): > OT: Did IBM marketing morons rebrand DB2 into Db2 to make it easier to type > it without errors on smartphone and tablet virtual keyboards? I looked at it and thought of the musical notation for the note D-flat, which is enharmonic with C-sharp. Since C# is now Microsoft's favourite programming language, I expect the IBM marketing people had their instructions. ... :-) -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More musings about Unicode, UTF-8, etc.
On Mon, 11 Sep 2017 11:49:29 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: More musings about Unicode, UTF-8, etc." (in <0662287305026690.wa.paulgboulderaim@listserv.ua.edu>): > On Mon, 11 Sep 2017 16:41:18 +0100, David W Noon wrote: >> >> I have added these strings to my code and the results are the same as >> yours. I suspect the rendering software does not handle CJK characters >> very well in Indo-European locales. >> > I'm calling it a font problem: The CJK characters display double-width, You are correct. I am using a fixed pitch font, but it uses 2 character cells for the CJK characters. [snip] >> There is a Makefile included that can build the source code using either >> GCC or CLANG using gmake. Those who use other C/C++ compilers will have >> to work out their own build sequence. >> > Fails for me with: > > 525 $ make > make: gcc-config: Command not found > make: gcc-config: Command not found Which operating system are you using? You should have received the gcc-config command as part of your GCC toolchain(s). This command allows you to select from multiple versions of GCC installed. I developed the code on Gentoo Linux. Such a system can have 5 or 6 GCC toolchains installed concurrently, so gcc-config is a must have. > make: Warning: File 'Unicode_test.cpp' has modification time 19042 s in the > future I'm in the BST timezone, so I'm 5 hours ahead of NYC and 8 hours ahead of LA/SF (and Redmond, WA, for that matter). > /g++ -o Unicode_test -pipe -std=gnu++14 -Wall -Wextra -O2 > -fomit-frame-pointer Unicode_test.cpp -Wl,--as-needed,--strip-all > make: /g++: Command not found > Makefile:13: recipe for target 'Unicode_test' failed > make: *** [Unicode_test] Error 127 If you edit the Makefile to remove the shell subcommands that invoke gcc-config and remove the slash separator, you should then access gcc and g++ through your PATH environment variable. > o I'm surprised that the fake text file survived network newline conversions. I concluded that Listserv was pretty dumb, so I felt that an attachment with a filename ending in .txt would survive. > o .zip is timezone-ignorant. Yes, it's derived from an old MS-DOS/PC-DOS command and those systems did not know for timezones when PKZIP was written. The archive file format does not permit timezone data. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: More musings about Unicode, UTF-8, etc.
On Sun, 10 Sep 2017 22:57:18 -0500, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: More
musings about Unicode, UTF-8, etc." (in
<6975604789454628.wa.paulgboulderaim@listserv.ua.edu>):
[snip]
> = zsh
> Привет мир. +++
> Emmanuel Macron +++
> 문재인 +++
> Enrique Peña Nieto+++
> Владимир Путин+++
> Donald Trump +++
> 习近平 +++
>
> = bash
> Привет мир. +++
> Emmanuel Macron +++
> 문재인 +++
> Enrique Peña Nieto +++
> Владимир Путин+++
> Donald Trump +++
> 习近平 +++
> ...
> zsh is not ideal, but still the best.
I have added these strings to my code and the results are the same as
yours. I suspect the rendering software does not handle CJK characters
very well in Indo-European locales.
I am attaching the zip archive to this message as a fake text file.
Rename it from Unicode_test.zip.txt to Unicode_test.zip and it should
unzip in the usual manner. It contains a directory to hold all its
files, so you can unzip it safely, without polluting another directory.
There is a Makefile included that can build the source code using either
GCC or CLANG using gmake. Those who use other C/C++ compilers will have
to work out their own build sequence.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
PK
0+K
Unicode_test/UT
몶Y½}°Yux è è PK d+K ?$8± ! Unicode_test/Unicode_test.cppUT
»¤¶Y¦¶Yux è è ¥VÍnÛF>[O1pF9q $°
µ¶ I
¤ì(`¬Éµ
ÅU¤
£¤OÐÞûó 9ôpÐ=ôäwhÍCtfEÇrÚظÜùæo;\]
ÑÇFL ÔPÊ¢a®J(ªéTTîÊJ§ÑX]
x¬
Ö
$$z2ULAdùàC ÿðNUA®q¡ÍËó¤
Ha2%
<õÛdR"p\==3êx\BÓmÁÚýÛÐ'*
ýøZç q¬MFÒÈ´Ó»sò65E'®ò9c
]iàîx*y!ÉüBª¢4ê¨*Î-ݪ¤K¡+H»s¤raÎ`¤Í¤hc.åÓSW%¡LtªF*Ña$L¥¨²D¨(¦r,JËe¤³Lªü
ç©"§,,×kjo+@.YÙLm,²%\q¤Oè¨V0DÇÛhÂdG(qóô-R3ÉPYþ[PäæVHí
yü7tþ9Vgªj"óR\l«¡ñÄÀºI¬¸Ý çÔéùRY_ÎÅD-Z#á«M+¾*ˤò96Æ<£/¥¢ÃïLæ)îJêä0Ñ¥¹4زØ
;Fx0G²bzTR×Ô-ÅT&ÔPè©¨Ó µR>oª¢¨©Û¶ïó¢`;ÞwB¸ Á ï± tð
B¾Ó¡ x=Fàø=ÜõãwqF³ìDè¼lÏ ÿ ØGE!ðÝÇ sµû®7ìq§
~Çwyqж¡ÿí Á6ì²Ðíã«Óå lÈm ûn;
ÈÆÜ zNa8"_G®çð]Öà ÈǸÀö CÔw<ïzºìû,¤ Ó
.C¦N×cÎfÛã!scJëjå¢HÒkP4`.Ç5êÂ0)'<h×°{<D;<³ëì`ÍÛÕÁ"¹Ãíw$v£ÇÃÁNô¬ì ÷¸Ë¢
ðÈ
7%ÓsbÇG-pÝ FÜJÈý
ápóÀoaÍ÷Q!dê
wÏj øó¼wX 4éa«Ñý>Ãý䵪9$Gê¹ñ¢D1mbWùÏv<¾Ã|A@@û<b-, ÈÛàØvhs§¢!7[®íëíܶվ
NoÿÚ û!âuûXùÜ~>}«Æ{*O²
oÈM¥ñsb²µ°G@~¼¸s"üw2L.îÐ[ÊKüæUÞ<Ñ*m5>m,eº¾>Ù´ëÓ:ÌÂq¶QÖxHSÎ=jøê =Ú<MÆ [°
ÊáÑY)Ñg£ÑXÂáú¸Þ6SÀIp5Ï-¤½ñö½Ö:ì*vgZãÃ#<izË},ìk¥åÖÆ
³¯/ÏÎgßÏ~ºx³_fçÏoñ`È+Á®HÎo6þûåùë¯^¾þòüÌܨ§ó@þþ _ÉRßBûÙϳog?"uË0Ï.^àë¯7;öt.²bSM¦7[þñê¿~ûüÏW?ÜlÖÕù'T§
§5N:iÕ³eô´âíotu<¶£¯zl,)q]Í6à´ em
¨/D#®Àúâð
&6RÞ'?X¿ÖsÆöçRÝb³¹¹ØRz]4ñ¥µÈËw%¤NzlnDTÞÅdI:ÌËq³h±mðëÑíËbqîÁ¢_îÀ téY ·¯§rTeÙYÛâiVá¸TÇø»`)EkÐóÿ"1Ræ·ó]^YYù8_FTÅÿ¥Êäp£ñ¬ñPK -¢(KHÎ
- Unicode_test/MakefileUT Æì²Y¦¶Yux è è AKÄ0
ÏÍ¯Ø ¶ÔéRñ
ÅZY/+.¸Ë %¦ÓLFñç;+=¸ê%¼¼ùf2 ¸/ÔhCÐ8mÇ.Õv»Þ\Ý>%öº'À!Ôek_Ó4?<Hcø¤÷à%àý)`ã: °ñ²#춼¨~$äùë77à`N娦õ¼î)¢ª2^ÏÄÄV)TÎ6º¼NVl?ÿqü=MÅb^oÌ[÷ À'mkí2Ò¶ ~I2Tð`ìV®¦Ç@Cýn}>*!æ÷E4wê{ÅKn :/a4ã/Ø~-%ѸÎ0q3nIÕ
ôF¶Qê»cà PK \+KJÑzj Ä Unicode_test/Unicode_test.geanyUT
@«¶YCª¶Yux è è ¥QÁNÃ0 ½ç+vá Ý80©Ê¡MBNK5E^ëm6 ¿Ç¡ Ä
Ujûü^^í[ËÖª³Í ëvz ]ı¶!WÓønè
ö [7 émÒi¦ª·¶C·q¶ÖAg Ì·] Áqd#
çÎÄ Í" ð9ªkÑ1°õnF`¶å½¾:B~¨§G´jEVÍU
ξ?jY92¹ÔûåUò/"]+=ê'ga
cdµ( 9Zì}E{pEÇâTYÈ}±¾SZL;ïv4Iôi9R1ã6poÖ$-}Wóv®gy2ûf
JQìPjyw¿07 S겺=?¯Êjñ´Z^Ì«©<eu6[¦ò
ò>FßÓ°¿àe ¾:ñ&ÿ¸¯ólýi¬êçÕB& MkéaªPK ô+KÝ(G" Y
Unicode_test/UTF8_test.cUT
¨¶Y'©¶Yux è è ¥VÝnãÖ¾bÖÖ²-{×{Å:¢hLª$µ®E I§!yÔsHn°@<A{ßÈE
Ú¢}ï;´@æ!úÍ!eËN^ôFâùo¾33Ïvi¬ÕB§U*a*$Çû/ÉÔ«ÒÉÜn'YJC«öf)ÄÌðý©
L+¥ÜÃCRò´úvu»ÏvÉU«-Ëzî½x~øAéÑùJDN½cH #ô ti¬ÕLÍI>ÉEj`©.gBSµ4ú3ìÞÐHf¢4
X.3i*-§u%UIi !#Ø£j
»3eªoh®taút-«%çUW¬¥P39YÊ:újA+¡ YUÀ *à>ªeZY,sçêZ .g
YM¢zÕB{
ίQYO1ТJõ¦SuÅG-¬¨T<îãÉ¡µlÚ-g@Áf§²@d¾ Ìm0²?g5
Ý!iìßÁù¿4ºZ?g*« QVé:dÏ
M'LssO»
´îBZYV]¦
`Xü
À÷|YµSe£Ei7Þ5'
Re: More musings about Unicode, UTF-8, etc.
On Mon, 11 Sep 2017 12:16:41 +0800, Timothy Sipples (sipp...@sg.ibm.com) wrote about "Re: More musings about Unicode, UTF-8, etc." (in <of77ca7f77.8afd0e88-on48258198.001747a1-48258198.00178...@notes.na.collabserv.com>): > David Noon wrote: >> The script that will never work is for bash (another UNIX shell). > > I don't understand this sentence. Nor does Rocket Software, I assume: > > http://www.rocketsoftware.com/zos-open-source/tools My statement was about the script, not the shell. The issue is the printf command. bash uses an external command /usr/bin/printf. This, on my system, is part of Linux's coreutils package. AFAIAA, there is no impetus to make coreutils Unicode-aware. In contrast, zsh uses a shell intrinsic for printf. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
More musings about Unicode, UTF-8, etc.
Hi folks, I have been doing some experiments on rendering Unicode and determining the length of rendered text compared to its storage in bytes. I have used Paul Gilmartin's 3 lines of text as sample data. I have 4 programs/scripts, of which 3 work and 1 can never work. The working programs are in C and C++, plus a script for zsh (a UNIX shell). The script that will never work is for bash (another UNIX shell). If anybody is interested I will post the code here in a zip archive. Any takers? -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CSST question
On Sun, 10 Sep 2017 09:40:09 -0700, Charles Mills (charl...@mcn.org) wrote about "CSST question" (in <0b3a01d32a53$776116a0$662343e0$@mcn.org>): [snip] > Is that saying that there is a chance that another CPU might observe a > condition in which the store of the first operand had occurred, but the > store of the second operand had not? My understanding from earlier > paragraphs was that CSST happened "all at once" from the point of view of > other CPUs. Was I mistaken? My reading of PoOps is that CSST is guaranteed to be atomic, just like the other instructions in the compare-and-swap family. So your first understanding is correct. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UTF-8 woes on z/OS, a solution - comments invited
On Tue, 5 Sep 2017 10:19:45 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in <2075516733653603.wa.paulgboulderaim@listserv.ua.edu>): [snip] > What language(s) cleanly handle vertical alignment of formatted text output > when > the text contains UTF-16 supplemental/surrogate (not in the BMP) characters? Python and Java, at least. > Here's an example of /bin/printf's failure for similar input with UTF-8 on > MacOS: > > The script: > printf "%-22s+++\n" "Hello World." > printf "%-22s+++\n" "Привет мир." > printf "%-22s+++\n" "Bonjour le monde." > > writes: > Hello World. +++ > Привет мир. +++ > Bonjour le monde. +++ > > I wish the "+++" would line up (at least in a monospaced font). This is a bug in your printf UNIX command. It is counting bytes to determine print position, rather than counting glyphs. It probably isn't Unicode-aware. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UTF-8 woes on z/OS, a solution - comments invited
On Tue, 5 Sep 2017 16:33:43 +, Pew, Curtis G (curtis@austin.utexas.edu) wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in <cdcfa846-0e36-494a-96cc-bc90f69e9...@austin.utexas.edu>): > In Python 3, at least, the built-in substitution facility can handle it as-is: Python 3 uses UTF-32 for all its default character strings. This relieves the problem of counting bytes or counting glyphs. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UTF-8 woes on z/OS, a solution - comments invited
On Mon, 4 Sep 2017 17:07:08 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: UTF-8 woes on z/OS, a solution - comments invited" (in <02b401d325da$f0cb4d30$d261e790$@mcn.org>): > COBOL or Java, but what about the OP's PL/I? IBM Enterprise PL/I has WIDECHAR(*), which supports UTF-16. It also has the UTF8(), UTF8TOCHAR() and UTF8TOWCHAR() built-in functions that translate host code page to UTF-8, UTF-8 to host code page, and UTF-8 to UTF-16, respectively. These will probably handle UTF-8 translations more reliably than IND$FILE does. The problem is the complexity that was previously hidden is now visibly the province of the programmer. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: dumb VSAM KSDS & AIX question.
On Wed, 30 Aug 2017 15:35:47 -0500, John Mckown (john.archie.mck...@gmail.com) wrote about "dumb VSAM KSDS & AIX question." (in <caajsdjimcsbansqo2xfgmfwsy22yfx8sm1ybznn+xi_zy5o...@mail.gmail.com>): > A programmer came by with a question. He asked if, when you are reading a > VSAM KSDS via an alternate index (PATH), to have duplicates returned in > base key order. I don't think that is possible. It depends on how much effort you are prepared to put in. VSAM, by itself, will not do it. > From examining the contents > of the AIX records themselves, it appears to me that the base key for a > "new" base record with a given alternate key is just placed at the end of > the keys. Yes, I know, if this sort of thing is a requirement, we need Db2 > (or is it DB2), but that is _never_ going to happen around here. It is DB2. But that isn't really necessary. You can order the records however you want using DF/SORT or Syncsort. Simply use the path as your SORTIN. If you are using COBOL then a SORT verb can do it too. If you are using PL/I then PLISRTA(), PLISRTB() and PLISRTD() can do it. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL STOP RUN enhancement
On Thu, 10 Aug 2017 07:04:02 -0500, John Mckown (john.archie.mck...@gmail.com) wrote about "Re: COBOL STOP RUN enhancement" (in
Re: Curse you, L-Soft!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Aug 2017 12:36:00 -0500, Elardus Engelbrecht (elardus.engelbre...@sita.co.za) wrote about "Curse you, L-Soft!" (in <8733075135946583.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>): > David W Noon wrote: [snip] >> Hash: SHA1 > > You're using SHA1, not SHA256? Ok, what e-mail software are you > using. If you don't want to answer, this is fine with me. The hash does not need to be particularly secure for signing, so SHA1 is plenty good enough. Even MD5 can still be used. I used Claws Mail to send that message. I am using Thunderbird to send this one. Claws is much more RFC-compliant than Thunderbird. >> You might see this message encoded as Base64. I am including a >> cryptographic signature and that usually requires a binary-safe >> encoding. > > Yes and I see this too: "-BEGIN PGP SIGNATURE-" I'll add a PGP signature to this message too. Thunderbird probably will not encode it as Base64 as T'bird is not RFC-compliant (or at least not as compliant as Claws). The only reason I do not use Claws all the time is because it does not always play nice with the MDA I use. SECOND ATTEMPT: === LISTSERV does not accept messages signed with an attachment, only with an inline signature. The first attempt was rejected by LISTSERV. So we'll try again. > I don't remember I ever see that, but I can see your reply on > IBM-MAIN properly, but when I "quote" your reply while composing my > own reply to you and to IBM-MAIN via web-site, all your reply is > encrypted. I don't know what MUA(s) you are using, but I would feel inclined to use something else if I were you. > I believe someone posted an URL where you can place that encoded > message and that site can translate it for you into readable text. All UNIX-like systems have command-line utilities to decode Base64 into original text (or even binary). It has been many years since I last used Windows. I don't think I could live with its limitations these days. - -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -BEGIN PGP SIGNATURE- iHoEARECADoWIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYoYohwcZGF2aWQudy5u b29uQGdvb2dsZW1haWwuY29tAAoJEKIGIHCOFv+UOIsAoLka/l+PWUvbLKC5fcAx ve+/4TI5AJ9CskfP8ZF3m+5R+x1yr8zswW4ymQ== =WN/U -END PGP SIGNATURE- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curse you, L-Soft!
On Tue, 8 Aug 2017 09:16:18 -0500, Paul Gilmartin (Paul Gilmartin) wrote about Curse you, L-Soft!: [snip] > According to various experiments and headers of off-list messages: > > MacOS Mail.app sends utf-8 as quoted-printable but deals corectly with > incoming 8-bit/ > > From one set of mail headers: > User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 > Thunderbird/52.2.1 > Content-Type: text/plain; charset=utf-8 > Content-Transfer-Encoding: 8bit Mutt has always been very RFC-compliant. > From another sent from Outlook/Windoze: > Content-Type: text/plain; > charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > WTF!? Why encode us-ascii? 7bit should suffice. But every blank > was encoded as hex 20!? Microsoft sets the standards. > A message I sent with mutt to IBM-MAIN; Cc: e...@univie.ac.at was > reflected by echo with an 8bit header so I assume that's what mutt > uses. But IBM-MAIN REPROed it as quoted-printable. Still phobic of > 8bit. > > A "non-blank blank" might be either a nonbreaking space or an > en-space. 8bit utf-8 should suffice for those; no need for base64. Another problem with a non-breaking blank is finding a MUA that respects the non-breaking attribute. > RFC 822 limits records to 999 bytes, give or take a . Longer > records require some encoding. But some MUAs, phobically, encode any > message containing records longer than 80 bytes. I blame a desire to > accommodate antediluvian IBM conventions for this compulsion. RFC 822 has been doubly obsoleted, by RFC 2822 and RFC 5322. The latter specifies 998 bytes as the line limit with a CR/LF pair added to make 1000. It also recommends a limit of 78 bytes, plus CR/LF. This is why lines of more than 80 bytes in total can induce encoding. > And encoding might be needed to protect a "From" message separator. I > recall one MUA that encoded every "F" anywhere in a message as hex 46. > My first guess at its motivation was probably wrong. The "From" separator is peculiar to Berkeley/Eudora mbox mail storage, although there are many recensions of this. Anything else should not escape this as ">From", even though some MDAs and even some MTAs do this, but the usual culprit seems to be mailing list forwarders. I see lots of paragraphs that begin with "From" that have been decorated to ">From" even though no mbox storage has occurred along the way. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curse you, L-Soft!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 8 Aug 2017 01:45:22 -0500, Elardus Engelbrecht (Elardus Engelbrecht <elardus.engelbre...@sita.co.za>) wrote about Re: Curse you, L-Soft!: > David W Noon wrote: > > >Sometimes Base64 or other binary-safe encoding is required by RFC. > > So I see. Thanks. Wish Shmuel is here, he certainly has something to > say about all these RFC requirements... Shmuel Metz has something to say about almost everything. ... :-) You might see this message encoded as Base64. I am including a cryptographic signature and that usually requires a binary-safe encoding. > >MTA = Mail Transfer Agent > >This is/are the SMTP server(s) used to move email around. > >Using a fully RFC-compliant MUA can cause many problems for those > >who use "cowboy coded" MUAs. > > >And to complete the email glossary: > >MUA = Mail User Agent (your mail reader) > >MDA = Mail Delivery Agent (the server from which your MUA downloads > >mail) > > Thanks for your kind help and the list of those glossary. I'll ask my > SMTP colleague about this. > > Thanks again! Much appreciated. My pleasure. - -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -BEGIN PGP SIGNATURE- iF0EARECAB0WIQQj5Jtua8i7AnGK26uiBiBwjhb/lAUCWYnrugAKCRCiBiBwjhb/ lL5CAKDT8paMZN7aHzjYKlkxniKHDRUteACeJlLOx2LiWzEuXaWQbrWlgk+eemA= =b6P2 -END PGP SIGNATURE- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curse you, L-Soft!
On Mon, 7 Aug 2017 13:08:20 -0500, Elardus Engelbrecht (elardus.engelbre...@sita.co.za) wrote about "Re: Curse you, L-Soft!" (in <6156763411207138.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>): > Paul Gilmartin wrote: > >> I can neither submit an SR to L-Soft nor rant on the L-Soft mailing list >> because I'm not a registered L-Soft customer. > > I feel your pain. I also wanted to moan and b*tch about base 64 encoding > amongst other things, but ... Sometimes Base64 or other binary-safe encoding is required by RFC. >> o When I attempt to reply to a submitter rather than to the list, my >> message is usually bounced by Rules at the recipients MTA. It might help >> greatly if LISTSERV added a proper "Sender:" header. > > Uh, I'm not understanding you? What is MTA? I only respond via web-page, not > via my own e-mail client software like Outlook. Else, I just copy and paste > the sender's address manually, a real PITA, but there is not really an > alternative AFAIK. MTA = Mail Transfer Agent This is/are the SMTP server(s) used to move email around. [snip] > But I have a gut feeling it is about the poster own e-mail attributes to > L-Soft which causes much grief to you and perhaps others too. > > I don't blame them too. Perhaps my OWN (and yours too) posting is causing > trouble to them too... Using a fully RFC-compliant MUA can cause many problems for those who use "cowboy coded" MUAs. And to complete the email glossary: MUA = Mail User Agent (your mail reader) MDA = Mail Delivery Agent (the server from which your MUA downloads mail) -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
On Tue, 25 Jul 2017 09:28:35 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: REGION=0M leads to CPU through the roof" (in <0d1501d30563$107e9a30$317bce90$@mcn.org>): > Not a huge expert but I do a certain amount of tuning of storage > requirements as the developer of a vendor product, and I have the > distinct impression that LE's initial program runtime storage > parameters are fixed at either compile or startup time and based on > supplied parameters, independent of the actual region size. That is, > there is no algorithm like "get half the free storage." It is "get X bytes." The change in memory consumption in the step termination reports would suggest that memory acquisition is varying with region size in this case. The fact that there is no S80A, S878, etc., abend would indicate that something inside the application knows how large the region is and does not exceed its bounds. COBOL programs are not usually that clever. > Of course, region size affects the possibility of an x78 failure if > the program requires more storage than initially obtained. That has always been its purpose. > I notice the OP, who was posting hourly or so, has gone quiet. > Perhaps the problem has been located. It would be interesting to know the final cause and resolution. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
On Tue, 25 Jul 2017 08:40:25 -0500, Tom Marchant (000a2a8c2020-dmarc-requ...@listserv.ua.edu) wrote about "Re: REGION=0M leads to CPU through the roof" (in <5654517605493549.wa.m42tomibmmainyahoo@listserv.ua.edu>): [snip] > I agree. Increasing the region doesn't ordinarily increase the storage > utilization. As a PL/I programmer of more than 40 years, I am sufficiently familiar with IBM's run-time libraries to offer a contrary experience. The start-up code for the old PL/I OS Optimizing compiler would check the VSM parameters and GETMAIN 50% of the remaining storage in the region/partition. [I wrote "partition" because this goes back to the OS/VS1 days.] The upshot was that the bigger the region one coded in the JCL the more memory the RTL would acquire at start-up time -- and would hold for the duration of the job step. It could acquire still more if the program needed it. One could override this by coding a PLIXOPT string in the OPTIONS(MAIN) procedure or by putting similar options in the PARM field of the JCL. Since LE is largely analogous to the old PL/I RTL, I would bet dollars to doughnuts that it will do something similar if allowed. Coding memory constraints in the RTL options can work wonders. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
On Mon, 24 Jul 2017 15:20:01 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: REGION=0M leads to CPU through the roof" (in <0b7901d304ca$fe76cda0$fb6468e0$@mcn.org>): > ELEVEN MINUTES of CPU time to manage the stack and heap??? It can happen when memory is in a lot of fragments. > Something is very wrong here. It's either a flaw in the measurement > process or something is very wrong in LE, MVS, etc. If it is eleven > minutes of heap management then I would say that is a PMRable problem. Indeed. But if the memory is being referenced (i.e. committed) when the memory management routines a trying to consolidate fragments, there could also be a lot of paging -- and paging really slows things down. > I would be checking my work -- the measurement process -- and then > reporting the problem to IBM. "Doctor, it hurts when I do this!" "Well don't do that." :-) -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: REGION=0M leads to CPU through the roof
On Mon, 24 Jul 2017 21:49:43 +, Way, Richard (richard@hpe.com) wrote about "Re: REGION=0M leads to CPU through the roof" (in <at5pr84mb0052b5a0bdde3c218dc53375ee...@at5pr84mb0052.namprd84.prod.outlook.com>): > Thanks! I'm a little reluctant to run a job that already takes 12 > CPU-minutes with RPTSTG(ON), but I may be able to cut the test data > back significantly and still see the relative increase, in which case > this may be very useful. I'll read through that tuning document as well! When you are fiddling with the LE parameters, you might also constrain the stack and heap sizes. Your excess CPU time could well be the LE memory management routines having to manage excessive amounts of virtual storage, and limiting the stack and/or heap could save much CPU. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Question regarding system symbols
On Thu, 13 Jul 2017 15:09:39 +0200, Peter Hunkeler (p...@gmx.ch) wrote about "AW: Re: Question regarding system symbols" (in <ez-296529166.2145179...@gmx.ch>): [snip] > For path /abc/xyzA1 this would be the commands > > cd /abc > ln -s /abc/xyza1 xyzA1 As a style nitpick, I would recommend relative paths in symlinks, e.g. cd /abc ln -s ./xyza1 xyzA1 The reason for this is, if the filesystem needs to be moved to another mount point than /abc, the symlink will automatically resolve to the linked directory even at the new mount point. HTH -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian
On Fri, 16 Jun 2017 17:56:42 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian" (in <7394087242781461.wa.paulgboulderaim@listserv.ua.edu>): > On Fri, 16 Jun 2017 22:56:18 +0100, David W Noon wrote: [snip] >> The endianness is determined by where the MSB and LSB are stored. On IBM >> machines the MSB is in the left-most byte of the register and the LSB in >> the right-most byte. That is big-endian. >> >> Ascribing indices to the bit positions in either order makes no >> difference. It is the order of *storage* that determines endianness. >> > ??? We're talking about *registers* here. See your first paragraph I quoted. > > What do you mean by "the order of *storage*" of bits in a register > other than how one ascribes indices? If I rotate my laptop 180° on > my desk, have I swapped the left end and the right end? The bytes are ordered, otherwise shift instructions would produce rather random results. The bits are ordered within bytes; that ordering remains fixed (i.e. bits are never reversed when loading/storing), even during shift instructions as bits are shifted in and out. You can see the byte ordering when coding an ICM or STCM instruction. These instructions have a bit mask to select affected bytes and the bytes are ordered in the same order as the bit mask -- and it is big-endian. >> The computers perform their arithmetic in whatever byte order the >> hardware designers choose. >> > If they operate serially, it's simplest if they start at the less significant > end. True, but a serial ALU can start at the LSB end, even on big-endian systems. >> My first system was a clone of an IBM 360. I felt dismay when I first >> read a core dump from a PDP-11. >> > That's one data point confirming my conjecture that people perceive > the conventions they learned earliest as Natural Law. I never cited it as "Natural Law". >> Fortunately, DEC realized that their design was crap and added a >> hardware instruction to put 16-bit binary integers into big-endian >> order; it had the assembler mnemonic SWAB (SWAp Bytes). The company I >> worked for in the 1970s exchanged data between many PDP-11s and a >> central IBM 370, usually without problems. >> > EBCDIC? Well, not if your data were entirely numeric. Hexadecimal floating > point? No. Text was in ASCII and binary data as integers; these PDP-11s did not have FPUs, so no floaters were used even in emulation. Note also that we did not use DECtape drives to exchange with the mainframe. We used a 9-track tape transport (spring tensioners, no vacuum columns) that wrote at 800BPI. The tapes had ANSI labels. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian
On Fri, 16 Jun 2017 12:55:53 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian" (in <2838801883027231.wa.paulgboulderaim@listserv.ua.edu>): > On Fri, 16 Jun 2017 16:43:38 +0100, David W Noon wrote: >> ... >> This is not the way computers do arithmetic. Adding, subtracting, etc., >> are performed in register-sized chunks (except packed decimal) and the >> valid sizes of those registers is determined by architecture. >> > I suspect programmed decimal arithmetic was a major motivation for > little-endian. AFAIAA, there are no little-endian platforms that perform decimal arithmetic as such, except on a byte-by-byte basis in a loop. The nearest I can offer is the Intel 80x87 FPU. This can load a packed decimal number [in little-endian order] into a floating point register, converting to IEEE binary floating point as it goes; reflexively, it can store a binary floater into packed decimal. However, all arithmetic is done as floating point. In fact, I have seen only 2 hardware platforms that perform packed decimal arithmetic: IBM and plug-compatible mainframes; Groupe Bull / Honeywell-Bull / Honeywell/GE / General Electric mainframes derived from the GE-600 series -- although these did not get packed decimal until they became the Honeywell H-6000 series. >> In fact, on little-endian systems the numbers are put into big-endian >> order when loaded into a register. Consequently, these machines do >> arithmetic in big-endian. >> > Ummm... really? Yes. > I believe IBM computers number bits in a register with > 0 being the most significant bit; non-IBM computers with 0 being the > least sighificant bit. I'd call that a bitwise little-endian. And it gives > an > easy summation formula for conversion to unsigned integers. The endianness is determined by where the MSB and LSB are stored. On IBM machines the MSB is in the left-most byte of the register and the LSB in the right-most byte. That is big-endian. Ascribing indices to the bit positions in either order makes no difference. It is the order of *storage* that determines endianness. >> As someone who was programming DEC PDP-11s more than 40 years ago, I can >> assure everybody that little-endian sucks. >> > But do the computers care? (And which was your first system? Did you > feel profound relief when you discovered the alternative convention?) The computers perform their arithmetic in whatever byte order the hardware designers choose. My first system was a clone of an IBM 360. I felt dismay when I first read a core dump from a PDP-11. > IIRC, PDP-11 provided for writing tapes little-endian, which was wrong for > sharing numeric data with IBM systems, or big-endian, which was wrong > for sharing text data. Text data were not a problem as the data were written as a byte stream. Binary data was where endian differences arose. Fortunately, DEC realized that their design was crap and added a hardware instruction to put 16-bit binary integers into big-endian order; it had the assembler mnemonic SWAB (SWAp Bytes). The company I worked for in the 1970s exchanged data between many PDP-11s and a central IBM 370, usually without problems. > For those who remain unaware on a Friday: > https://en.wikipedia.org/wiki/Lilliput_and_Blefuscu#History_and_politics I have long enjoyed Swift (not the programming language). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian
On Thu, 15 Jun 2017 20:33:13 -0500, John Mckown (john.archie.mck...@gmail.com) wrote about "Re: RFE? xlc compile option for C integers to be "Intel compat" or Little-Endian" (in <caajsdjg3xp-2cyaiea6xpre22z+ql60wwml2sy_o5xoo2bz...@mail.gmail.com>): > On Thu, Jun 15, 2017 at 5:05 PM, Frank Swarbrick < > frank.swarbr...@outlook.com> wrote: > >> The following link gives a few reasons why little-endian might be >> preferred: https://softwareengineering.stackexchange.com/questions/ >> 95556/what-is-the-advantage-of-little-endian-format. As a human I still >> prefer big-endian, regardless of any perceived advantages for little-endian! >> > > I must disagree with the "as a human" portion of the above. It is more a > "as a speaker of a Western European language using Arabic numering" > ( in UNICODE these are called "European digits") > . We got our writing direction, left to right, from the Romans (I'm not > sure where they got it). But we got our positional numbering system from > the Hindus via the Arabs (thus the "Arabic Numerals"). We write the most > significant digit on the left because they Arabs did it that way. But the > Arab languages are written right to left. So, from their view point, they > are reading the least significant digit first. I.e. Arabic Numerals are > written "little endian" in Arabic. Europeans just wrote it the same > physical > direction > because that's how they learned it. Using "little endian" is actually > easier. This would only be reflective of little-endian ordering if it used full bit reversal. Computers use bits, so any Arabic ordering would require all the bits to be reversed, not the bytes. > How we do it now: 100 + 10 = 110. In our minds we must "align" the > trailing digits (or the decimal point). But if it were written 001 + 01, > you could just add the digits in the order in which we write them without > "aligning" them in your mind. In the example, add the first two 0s > together. Then add the second 0 & second 1. Finally "add" the last 1 just > by writing it out. In a totally logical universe, the least significant > digit (or bit if we are speaking binary) should be the first digit (or bit) > encountered as we read. So the number one in an octet > (aka byte) > , in hex, would be written 0x10 or in binary as b'1000'. This is not the way computers do arithmetic. Adding, subtracting, etc., are performed in register-sized chunks (except packed decimal) and the valid sizes of those registers is determined by architecture. In fact, on little-endian systems the numbers are put into big-endian order when loaded into a register. Consequently, these machines do arithmetic in big-endian. As someone who was programming DEC PDP-11s more than 40 years ago, I can assure everybody that little-endian sucks. > And just to > round out this totally off topic weirdness, we can all be glad that we > don't write in boustrophedon style > (switch directions every line) ref: http://wordinfo.info/unit/3362/ip:21 That's all Greek to me. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
REFR protection (was: APF authorization and AC(00)
On Mon, 12 Jun 2017 11:35:33 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: APF authorization and AC(00)" (in <3613995808381310.wa.paulgboulderaim@listserv.ua.edu>): [snip] > Earlier, I said that REFRPROT could be made the default because load > modules erroneously marked REFR could be re-linked. OK. Not in > every case. So make REFRPROT the default except for load modules > marked non-editable, because they can't be repaired. The PDS utility and/or File-Aid can remove the REFR attribute, so there is no need to re-link. The attribute is in the directory entry. > REFRPROT should be made a JOB statement option rather than a system > parm option, for flexibility in testing. More granular than that, it should also be available on the EXEC statement so that it can be selected on a step-by-step basis. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Tue, 23 May 2017 12:27:10 -0400, Tony Harminc (t...@harminc.net) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in
Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)
On Mon, 22 May 2017 10:57:26 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: RACF Database (was: Sample JCL for file transfer using NJE/TCPIP)" (in <507b5253-a062-4547-91f6-3de9e6f3b...@aim.com>): On 2017-05-22, at 10:01, Jesse 1 Robinson wrote: ... Nonetheless ACF2, based on VSAM, was well established ... ... In any case, a SAF product has to be available extremely early in IPL, ... How does ACF2, based on VSAM, meet this requirement of early availability? ACF2 is supposed to start before JES2/JES3. It is configured as a subsystem and its PARM field includes the name of the job entry subsystem to start (i.e. ACF2 starts JES). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JCL null statement
On Tue, 9 May 2017 16:33:35 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: JCL null statement (Was: job output into dataset" (in <2883779052307729.wa.paulgboulderaim@listserv.ua.edu>): [snip] What happens to any additional records between the null statement and the next JOB statement? are they quietly ignored (with perhaps a message to operator?) The IBM term is "flushed". They never hit the spool and no console message is issued. At what point if any in the logic does the access method recognize INTRDR as special, different from ordinary SYSOUT? QSAM doesn't distinguish between INTRDR and any other SYSOUT writer. VSAM detects on the OPEN and uses a specific form called JAM (JES Access Method). Does the // /*EOF ... that John M. mentioned cause flushing of any SYSOUT or only one with W=INTRDR? Only using INTRDR. Other SYSOUT streams have to tolerate any character sequence and cannot safely reserve them for commands to the writer (unless some custom writer can process commands). The other IBM writers do not have internal commands, AFAIAA. What happens if the operator issues "$TOJ W=INTRDR" on an ordinary SYSOUT data set after the fact? Probably nothing good. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
JCL null statement (Was: job output into dataset
On Tue, 9 May 2017 14:56:33 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <5975685166305075.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 20:20:10 +0100, David W Noon wrote: [snip] What kind of null statement did you use? The JCL null statement is coded as two slashes followed by blanks to the end of the card image (or column 72 at least). Two slashes and nothing else; no blanks. Do I need to have blanks? I think you will need at least 1 blank. I have never used varying length records for JCL, since I date back to the days of Hollerith cards, which were always 80 bytes long. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: job output into dataset
On Tue, 9 May 2017 13:25:43 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <679800532864.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 18:59:23 +0100, David W Noon wrote: The INTRDR writer will "spin" a job stream to the input spool automatically when: i) the job stream arrives at a null statement; ... I'm skeptical about that point since I often submit jobs with noise such as comments after a null statement and SDSF shows me those lines in JESJCLIN, indicating that the job was not spun until the SYSOUT was closed. What kind of null statement did you use? The JCL null statement is coded as two slashes followed by blanks to the end of the card image (or column 72 at least). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: job output into dataset
On Tue, 9 May 2017 12:52:19 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: job output into dataset" (in <3155439687677594.wa.paulgboulderaim@listserv.ua.edu>): On Tue, 9 May 2017 10:16:00 -0700, Lizette Koehler wrote: You can SPIN SYSOUT (I do not think you can SPIN INTRDR ) For INTRDR, the program can close it (and re-open or FREE and re-ALLOCATE.) I don't think I'd want to spin INTRDR by an external command unless I knew that data set was at a JOB statement boundary. The INTRDR writer will "spin" a job stream to the input spool automatically when: i) the job stream arrives at a null statement; ii) the job stream arrives at a new JOB statement; iii) the SYSOUT DD statement is closed. If an INTRDR stream does not release the job stream to the input spool then the submitter program is incorrectly coded. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Zip archives (Was: SHARE Proceedings self-extacting ZIP File reguesting Admin rights??
On Wed, 3 May 2017 11:11:55 +0200, Peter Hunkeler (p...@gmx.ch) wrote about "AW: Re: AW: Re: SHARE Proceedings self-extacting ZIP File reguesting Admin rights??" (in <ez-1466893888.2045657...@gmx.ch>): [snip] > What is "standard unzip"? Long ago, Windows had no ZIP support, so I > bought WinZip. Has the "unzip" become Windows command when support > for ZIP files was added? The original standard for .zip archives was established by Phil Katz's company PKWARE and its PKZIP product. This product was shareware but was never open-sourced, but the archive format was published. This publication produced the Info-Zip open-source project at U.C.L.A. and this project delivered the zip and unzip commands. These commands -- and they are commands, not mousey-clicky icons -- run on almost all systems: MS-DOS/PC-DOS, Win16/Win32/Win64, OS/2 (16-bit & 32-bit), MacOS, Linux, FreeBSD, OpenBSD, NetBSD, Solaris/SunOS, AIX, HP-UX and a whole bunch of others. Most UNIX-like systems bundle Info-Zip these days, as it is open source and freely distributable. PKZIP dates to about 1982. Info-Zip dates to about 1991. The standard for the archive is that published by PKWARE. The standard for the unzip command is that for Info-Zip. Here is the man page: <https://www.freebsd.org/cgi/man.cgi?query=unzip=1> -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can XLC printf() take "%D(*,*)"?
On Wed, 26 Apr 2017 10:01:06 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: Can XLC printf() take "%D(*,*)"?" (in <0dc501d2beae$b2613e30$1723ba90$@mcn.org>): > I don't seem to be able to declare a D variable in C++. > > I am coding the parameter to printf() as > > *reinterpret_cast<D(31,0)*>(value) A reinterpret_cast will only result in another pointer, as all it does is change the notional type but keep the bit pattern the same. An array is always a pointer in C/C++, so a char[] is always reduced to its address. > where value is declared as char[1] and contains (variable length, passed to > me as a parameter) the fixed point decimal data. The compiler is giving me > > line 1047.39: CCN5130 (S) "D" is not declared. > > (And yes, I #include without error.) > > I am starting to think this approach is hopeless (pending what if anything I > hear from Toronto). I think you'll need to use "C thinking" rather than "C++ thinking". My suggestion of using a struct is the best I have come up with so far. > I am currently using an interpretive loop to format the decimal data. I am > going to look into using __EDMK() instead. (And yes, the volume, potentially > millions of iterations per day, justifies the effort.) Do you know the size and scaling factor of the packed decimal values at compile time? If so, the __EDMK() call could be faster than printf(), as those format interpreters [printf(), sprintf(), etc.] often run like treacle in winter. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can XLC printf() take "%D(*,*)"?
On Wed, 26 Apr 2017 09:30:50 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: Can XLC printf() take "%D(*,*)"?" (in <0db001d2beaa$78b3c210$6a1b4630$@mcn.org>): > Thanks. I will take your suggestions to heart and give them a try but the > fact that the %D is printing as a D leads me to think that printf() is not > recognizing the %D at all. The usual action for a C run-time library is to print the format literally if the passed parameters cannot be recognized as conformal to the format. So a "D" can be expected. >> You should not be passing a pointer (); everything is passed by value. > > That may be a problem because I will then have to cast it as decimal and not > sure I can do that in C++. I am wondering how I am going to cast it as I > need to cast as D(s,p) and I don't know significance and precision at > compile time, only at run time. > > I wonder how C passes a potentially 16-byte string by value. The usual hack is to wrap the char[] (array of bytes) in a struct and pass the struct by value. Alternatively, you could wimp out and code this run of code in plain C. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can XLC printf() take "%D(*,*)"?
On Wed, 26 Apr 2017 11:09:19 -0500, Elardus Engelbrecht (elardus.engelbre...@sita.co.za) wrote about "Re: Can XLC printf() take "%D(*,*)"?" (in <7516686188585950.wa.elardus.engelbrechtsita.co...@listserv.ua.edu>): > David W Noon wrote: > >> You should not be passing a pointer (); everything is passed by value. > > Not many programmers are getting that right. Just that is making debugging > extremely painfully difficult. It's part of the C/C++ learning curve, I'm afraid. > I am just curious - Are there any compiler option(s) to help you to avoid > that specific error? Not that I know of. A lot of such problems went away when the old K dialect of C became deprecated. The C89 standard required functions to be specified by a prototype that defined the exact type of each parameter, and the compiler would match the type of the actual parameter to the type specified for the formal parameter. The problem really arises with "vararg" functions like printf() & co. These accept any argument in the second and subsequent parameter position(s), thus disabling the compiler's type matching. This is a major reason why I prefer C++ file streams to C's library routines for I/O. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can XLC printf() take "%D(*,*)"?
On Tue, 25 Apr 2017 16:07:38 -0700, Charles Mills (charl...@mcn.org) wrote about "Re: Can XLC printf() take "%D(*,*)"?" (in <0c5901d2be18$bc7c4900$3574db00$@mcn.org>): [snip] > But I consistently get 'D(*,*' for output. Here is my exact format: > "%*.*D(*,*)" and I am calling it with 20, 5, _number, precision, > scale. (I started out with 20, 5 like in the example just to make my life > easier.) Your parameter sequence is wrong. You need to pass: field width, by value decimal places, by value digitsof(x), by value precisionof(x), by value x, by value in that order. You should not be passing a pointer (); everything is passed by value. > Here's a rub. The code is C++ and fixed point decimal support is limited to > C ... but ... at the Spring TDM I asked a guy from Toronto why the heck the > fixed point decimal support is only C and not C++. He told me -- very > interesting story but I am going to play it safe here and assume it is under > NDA. But he did tell me that I could call printf() from C++ and format fixed > point decimal with no issues as printf() is a C function, not C++. I'm not sure what "limited to C" means in a C++ context. After all, C is largely a subset of C++, albeit with a few wrinkles these days. I could understand that STL has no piping operator or I/O manipulators for packed decimal, but the manipulation of packed decimal values in general code should really be the same for C and C++. However, I did not write the IBM compiler(s), so I don't know how much code the C and C++ compilers share. > I had not added decimal.h to my code as there is no packed logic other than > the printf() (data comes in from an external source). I added the #include > but still no joy. How are you declaring the decimal variables? -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Can XLC printf() take "%D(*,*)"?
On Tue, 25 Apr 2017 15:11:09 -0700, Charles Mills (charl...@mcn.org)
wrote about "Can XLC printf() take "%D(*,*)"?" (in
<0c3301d2be10$d87ed2b0$897c7810$@mcn.org>):
> I'd like to format fixed point decimal (packed, in other words) numbers in a
> common subroutine that would be passed the precision and scaling. Can
> printf() and friends take '*' and then a passed integer for its (n,p) values
> - analogous to the way printf() width and precision may be specified?
KC offers this:
<https://www.ibm.com/support/knowledgecenter/SSB27U_6.2.0/com.ibm.zos.r12.cbcpx01/pex1.htm>
This page contains the following:
printf("pd02 = %*.*D(*,*)\n",
20, 5, digitsof(pd02), precisionof(pd02), pd02);
This appears to do what you want, but you will need to specify the width
and decimal places for the output field too.
HTH
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: program-name is unresolved/uncallable
On Tue, 25 Apr 2017 14:12:20 -0500, Tom Marchant (000a2a8c2020-dmarc-requ...@listserv.ua.edu) wrote about "Re: program-name is unresolved/uncallable" (in <7268174283864055.wa.m42tomibmmainyahoo@listserv.ua.edu>): > On Tue, 25 Apr 2017 14:08:06 -0400, Farley, Peter wrote: > >> IMHO that is just sloppy application coding that would not pass a peer >> review by me. It is trivially easy to set and test a flag to remember you >> already issued a given message already and bypass issuing it repeatedly, > > I'd go even further and say that such a message should not be written to > the console. It is not something that an operator should be expected to > deal with. It probably was not intended to go to the console. Most of these messages begin life as a WTO with ROUTCDE=11, which is really intended for the programmer or application user. Unfortunately, some -- perhaps many -- sites reconfigure console routing so that these messages also go to route code 2 (or similar). This means that "general bumpf" goes to the console as well as to the job log. This can be a major annoyance to the operators, and the annoyance is exacerbated by the fact that the messages were never intended to go to the console in the first place. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: LLVM
On Fri, 21 Apr 2017 21:22:04 +0800, David Crayford (dcrayf...@gmail.com) wrote about "LLVM ( wasRe: Swift on z/OS (was Data/hiperspaces (was: ... 4G bar?))" (in <c6accf96-39c0-89b3-c91c-b3aef3258...@gmail.com>): [snip] > IBM have ported LLVM/clang to z/OS. The beta of swift gives the game away I have been using clang and LLVM on IA32 and AMD64 hardware for some few years now. The optimization of C/C++ code is quite good. > DOC:/u/doc: >swiftc --version > Swift version 3.0-dev (LLVM , Clang , Swift ) > Target: s390x-ibm-zos > > Interestingly they have a libbsd.a static library which appears to be a > shim of the the BSD C/C++ runtime library. No. The libbsd.a library contains some idiosyncratic, but more rational, variants of Standard C Library functions, particularly for string handling. I have been using these routines for some years too, and I generally prefer them to the ISO standard functions. Look for functions like strlcpy() and strlcat() as alternatives to strncpy() and strncat(). > Right now compiling Swift programs is agonizingly slow! And it's missing > the foundation/core library which makes it quite useless to do anything > meaningful. That won't stop IBM from releasing it as the hot new thing. It could soon be as fast as Java! -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Assembler question
On Fri, 7 Apr 2017 19:09:09 -0400, Tony Thigpen (t...@vse2pdf.com) wrote about "Assembler question" (in <58e81c15.6060...@vse2pdf.com>): [snip] > OPEN (HPPCTL,UPDAT) > HPPCTL DCB DSORG=PS,RECFM=F,LRECL=100,DDNAME=HPPCTL, >BLKSIZE=(100), >MACRF=(GM),EODAD=PPCTLOUT You have specified UPDAT in your OPEN but your MACRF only has GM. If you really are updating the dataset in place, you should have MACRF=(GL,PL), or if you are only reading the dataset then your OPEN macro should specify INPUT rather than UPDAT. For either INPUT or UPDAT, you do not need to specify RECFM, LRECL or BLKSIZE, as these will be taken from the format-1 DSCB. Specifying these unnecessarily can corrupt the format-1, as the access method takes your word for these values, not the existing ones in the format-1, so any differences are put into the format-1 during the CLOSE macro -- at least for UPDAT. HTH -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data/hiperspaces (was: ... 4G bar?)
On Thu, 30 Mar 2017 15:42:47 -0500, John Mckown (john.archie.mck...@gmail.com) wrote about "Re: Data/hiperspaces (was: ... 4G bar?)" (in <caajsdjh9t4--xdgjtuwg_4nufjpvk36fso8eyvpvy09j8c6...@mail.gmail.com>): > A very good point, especially about being callable from COBOL. So does > that mean that use of a hiperspace is supported by COBOL? Room for > discussion there, I think. COBOL and all the other compiler languages have had access to hiperspaces and dataspaces for decades, but by library call only. That's what the windowing services library has provided since MVS/ESA days. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Data/hiperspaces (was: ... 4G bar?)
On Thu, 30 Mar 2017 13:01:26 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Data/hiperspaces (was: ... 4G bar?)" (in <1090839201676758.wa.paulgboulderaim@listserv.ua.edu>): [snip] > ... HLL programs cannot use [data/]hiperspaces directly. > > How can it tell? Is there a flag in a control block indicating "HLL" > the supervisor checks and bars use of data/hiperspaces? The only API for manipulating dataspaces and hiperspaces is the assembler macro DSPSERV and such. No compiler languages have such a construct. Instead, compiler languages have to use IBM's windowing services library, which is written in assembler. So, any HLL has only indirect access to dataspaces and hiperspaces. > What's the definition of a "HLL"? Anything that isn't assembler. Some people think C is a LLL, but that's just wishful thinking. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Check out Massive Amazon cloud service outage disrupts sites
On Wed, 1 Mar 2017 09:02:47 -0800, Charles Mills (charl...@mcn.org) wrote about "Re: Check out Massive Amazon cloud service outage disrupts sites" (in <04c101d292ad$a751f750$f5f5e5f0$@mcn.org>): [snip] > Up here in northern CA we used to joke that PG's company song > should be the Simon & Garfunkel "Hello Darkness my Old Friend." Given that the song's title is "Sound of Silence", it would apply to stereo systems too. ... :-)) -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about PARMDD
On Wed, 22 Feb 2017 15:05:54 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: Question about PARMDD" (in <5643810626893433.wa.paulgboulderaim@listserv.ua.edu>): [snip] > This thread began with a discussion of the PARM string. I'd like to think of > JCL > as source code, not as data. You can consider JCL as whatever you wish. The point I was making was that the PARM string is data, not source code. > And I definitely think of JCL as sorely deficient > in string manipulation operations. It was developed a half-century ago, > subject to severe resource constraints. I first coded OS JCL under MVT more than 40 years ago. I coded DOS JCL before that, and OS JCL is luxury in comparison. I also coded GCOS JCL on Honeywell mainframes in the early 1980s; OS JCL is *serious luxury* in comparison to that, That said, I will not defend JCL's limitations. Its string handling is largely limited to symbolic substitution using syntax taken from the macro language of System/360 assembler. From the point of view of the average COBOL programmer it is almost impenetrable. Ideally, JCL should have civilized syntax for string manipulation and for flow control. This would include SELECT/WHEN/OTHERWISE, DO-loops. WHILE-loops as well as IF/ELSEIF/ELSE. The string manipulation would include conditional substitution (ternary operator?) as well as concatenation, extraction and removal of substrings, scanning strings(*) for patterns and a whole lot more. We're basically talking Python here, and a bit more besides. (*) I think regular expressions would send most mainframe programmers scatty, but it would be nice to have. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about PARMDD
On Wed, 22 Feb 2017 14:00:55 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: Question about PARMDD" (in <1294479713669226.wa.paulgboulderaim@listserv.ua.edu>): > On Wed, 22 Feb 2017 19:52:26 +, David W Noon wrote: >> >> You need to remember that the PARMDD file is read in and concatenated >> into a character string. The notion of comments inside a character >> string is rather a strange one to me, as a programmer who has been doing >> string parsing for decades. >> > And yet: > > 572 $ rexx > say 'foo'/*comment*/'bar' > foobar > > (Yes, I understand there's an implied concatenation operator there.) Indeed, you have two character strings with a comment separating them, then implicitly concatenated. Neither string contains a comment. More than that, you are processing source code here, not data. The REXX language defines comment delimiters and the language parser takes the appropriate action. In contrast the PARM string, whether coded as PARM or built from PARMDD, is almost invariably data. There is no comment delimiter defined for general data, as a data stream can contain anything in the most general case. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about PARMDD
On Wed, 22 Feb 2017 11:11:58 -0700, Lizette Koehler (stars...@mindspring.com) wrote about "Re: Question about PARMDD" (in <11166244.8506.1487787118...@elwamui-huard.atl.sa.earthlink.net>): > There is no one standard for Parmlib members and comments. > > You would need to see what the DB2 syntax is for this member. You need to remember that the PARMDD file is read in and concatenated into a character string. The notion of comments inside a character string is rather a strange one to me, as a programmer who has been doing string parsing for decades. As an illustration, it is directly analogous to putting comments into the PARM field: //STEP1 EXEC PGM=MYPROG,PARM='parm1, /* ignore this */ parm2' This requires the application to parse the PARM string in such a manner that the comment convention removes the comment text. The comment convention must, of necessity, be specific to the application program: there is no universal comment delimiter. My personal preference would be the one used in some ALGOL 68 implementations, the cent symbol '¢'. This would give us: //STEP1 EXEC PGM=MYPROG,PARM='parm1, ¢ ignore this ¢ parm2' It's more succinct than the PL/I comment notation used above, but anybody who has never used ALGOL 68 could find it confusing. But the bottom line is that PARMDD is *not* processed as a PARMLIB member, so comment lines are not applicable. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing between PL/I and C
On Wed, 22 Feb 2017 02:51:44 +, Ze'ev Atlas (004b34e7c98a-dmarc-requ...@listserv.ua.edu) wrote about "Re: interfacing between PL/I and C" (in <820814017.2236904.1487731904...@mail.yahoo.com>): > Do i need the pragma in the C program if iuse the enterprize PLI. No. Provided your PL/I declarations are accurate, the C code does not need any #pragma directives. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: interfacing between PL/I and C
On Tue, 21 Feb 2017 18:15:30 +, Ze'ev Atlas (004b34e7c98a-dmarc-requ...@listserv.ua.edu) wrote about "interfacing between PL/I and C" (in <2145241966.1868601.1487700930...@mail.yahoo.com>): > Hi all,I hope someone can guide me. I have a C library that I want to > call from PL/I. I actually have to create an intrface module for some > reasons. If I code it in C using #pragma linkage (..., PLI) I have no > prlblem communicating between the C and the PL/I, but then the C cannot > communicate with the rest of the library which is compiled without the > pragma (because it has to communicate with COBOL and the rest of the > world). I am considering doing the interface in Assembler. Which PL/I compiler are you using? If you are using Enterprise PL/I then you should simply be able to declare your C functions and subroutines in PL/I with the appropriate parameter attributes. All of C's attributes are available in PL/I and have been for over 20 years. If you post a couple of C prototypes here, I shall translate them into PL/I for you and you can use them as examples. Post the most complicated one(s), typically those with the greatest variety of parameter types. If you are still using the old OS PL/I Optimizer, good luck -- you'll need it. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BSAM vs QSAM
On Sat, 4 Feb 2017 13:24:41 -0500, Jim Mulder (d10j...@us.ibm.com) wrote about "Re: BSAM vs QSAM" (in <ofee80157a.02b94811-on002580bd.0064ecec-852580bd.00652...@notes.na.collabserv.com>): > I asked Wayne Rhoten. His recollection is that SAMe GAed as a product > around 1978, > and was integrated in the early 1980s. This gels with my experience. In the early 1980s I was working as a GCOS systems programmer on Honeywell/GE mainframes, with little contact with IBM boxes. When I returned to the IBM fold (c. 1984) I found that SAM had been largely re-architected and was much as we see it today (except it was still 24-bit). The revised SAM was definitely bundled with DFP/XA, but did not become 31-bit code until MVS/XA SP 2.2. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BSAM vs QSAM
On Sat, 4 Feb 2017 02:06:16 +, Jesse 1 Robinson (jesse1.robin...@sce.com) wrote about "Re: BSAM vs QSAM" (in <by2pr0101mb080862ff8074b4fdc8c84877bf...@by2pr0101mb0808.prod.exchangelabs.com>): > I'm bowled over by David Noon's post. Pleased to be of service. ... :-) > I did not know that QSAM allowed asynchronous I/O operations and have not > looked > into coding requirements. The operations are synchronous at the application level, but asynchronous for the physical I/O transfers. > At the same time I contend that system managed interleaving is not the same > thing. > While it undoubtedly speeds up I/O for 'traditional' QSAM, the application > program > remains in a WAIT during all the background happenings and cannot independently > fiddle with bits and bytes pending I/O completion. The I/O transfers are behind an opaque API. They run asynchronously from the program, but the program synchronizes every time it uses a QSAM API (i.e. a GET or a PUT). With a decent sized buffer pool, most GET requests return immediately with the required record. The program only occasionally enters a WAIT/CHECK condition. Similarly, most PUT operations copy the data record from the work area into the buffer pool and return to the program immediately. The buffer will be queued for flushing when it becomes full. All of the buffer fills and buffer flushes occur quite separately from the application program. The EXCP macro is a wonderful thing. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BSAM vs QSAM
On Fri, 3 Feb 2017 16:54:57 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BSAM vs QSAM" (in <4092052368963851.wa.paulgboulderaim@listserv.ua.edu>): > On Fri, 3 Feb 2017 14:42:24 -0500, Farley, Peter x23353 wrote: >> >> OTOH you don't have to wait for completion of a READ or a WRITE. You can >> issue a WRITE at the end of a processing loop and then go back to process >> the next record while the WRITE completes, and only CHECK the WRITE when you >> are ready to issue the next WRITE. >> >> Similarly for READ's, issue another READ right after the start of processing >> for the prior record, then CHECK the second READ when you come back to the >> top of the processing loop. >> > Does QSAM not overlap I/O with processing? I had expected that on the first > GET > QSAM would issue BUFNO READs; CHECK the first and return the record for > processing > while the remaining BUFNO-1 READs proceeded. This is correct for QSAM in the last 35 years or so. Older versions of OS did not offer asynchronous transfers as far as the calling application is concerned, but modern QSAM uses the application API (i.e. GET and PUT macros) as the point[s] when transfers are synchronized. Between GETs and PUTs, I/O transfers continue in the background where possible. For most applications, there is no real benefit in using BSAM. > Another concern if you need to support BPAM is that BPAM and BSAM can share > more > code than BPAM and QSAM. That's fairly marginal. Much of SAM/E is in the LPA. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Paper tape (was Re: Hidden Figures)
On Fri, 13 Jan 2017 14:21:58 -0600, Tom Marchant (000a2a8c2020-dmarc-requ...@listserv.ua.edu) wrote about "Paper tape (was Re: Hidden Figures)" (in <3742476116017335.wa.m42tomibmmainyahoo@listserv.ua.edu>): > On Fri, 13 Jan 2017 13:56:57 -0600, Mike Schwab wrote: > >> https://en.wikipedia.org/wiki/Punched_tape >> About 1974-75, I lived with my dad, manager of a Kroger store. At >> night he would insert various strips of punch film into a reader to >> report the store's daily transactions. > > Well into the 1970's almost every mainframe shop used paper tape. > > What was it used for? In the mid 1970s I was working for a multi-national chemical company in Melbourne, Australia. We had 2 paper tape readers and 1 paper tape punch. They were used mostly for threatening young programmers who spoke derisively about punched cards. ... :-) -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: New free / open source z/OS tools from Dovetailed Technologies
On Fri, 13 Jan 2017 13:36:16 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: New free / open source z/OS tools from Dovetailed Technologies" (in <9549369497181383.wa.paulgboulderaim@listserv.ua.edu>): > In UNIX I believe that's not automatic. The application, compiler, > whatever, must parse that environment variable, breaking it at colons > and sequentially search each directory in the list. (Might there be a > library routine for that?) strtok() and strtok_r(). The first one is ISO standard C and the second one is POSIX standard C, at least according to the man page. See man 3 strtok on any Linux or BSD system. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Wed, 11 Jan 2017 10:12:30 -0700, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in <e858c541-1247-484b-a475-6ef8b5f65...@aim.com>): > On 2017-01-10, at 17:46, David W Noon wrote: >> >>> And how would you preserve one of the aboriginal design objectives of >>> OS/360: >>> the ability to ENQ all needed resources before job initiation to avoid >>> deadlocks. >> >> That went out the window with the arrival of MVS/370, which introduced >> SVC 99. >> > I believe ENQs with job scope remain in "the bread and butter of > commercial data processing." You mean "job duration". That bread would be a bit stale these days. There has never been a guarantee of no deadlocks. The pre-emptive ENQs issued by the initiators have only been a best effort at preventing deadlocks. For the last 37 years or so, dynamic allocation has been able to generate deadlocks whenever the design of the allocation strategy has not take deadlocks into account. >> Well, MVT was a single address space system. All regions were in >> separate extents of the same physical address space. >> > I see some suggestion in this thread that the same DDNAME can not > refer to different data sets within a single address space. But > didn't MVT work that way? No, it did not. Under MVT, OS/VS1 and OS/VS2 the TIOT was associated with a region (or partition under OS/VS1), not an address space. The dataset associated with a DDNAME was specific to a region/partition, but could vary across regions/partitions. > Each job (up to 15, limited by storage > keys?) could use common DDNAMEs, such as SYSIN, SYSPRINT, SYSUT1, ... > referring to different data sets. How have we lost that facility? No, we have not. That's because from MVS/370 onwards, each region is its own address space. So SYSIN, SYSPRINT, etc., in different address spaces can refer to different datasets, SYSOUT classes, etc., but within an address space a DDNAME remains tied to a specific dataset (or whatever). -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DAIR?
On Wed, 11 Jan 2017 10:22:01 -0700, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "DAIR? (was: "task level" TIOT & XTIOT? ...)" (in <d5b63de2-d515-4c19-a3ec-1ac7aa59d...@aim.com>): > On 2017-01-10, at 17:46, David W Noon wrote: >> >>> And how would you preserve one of the aboriginal design objectives of >>> OS/360: >>> the ability to ENQ all needed resources before job initiation to avoid >>> deadlocks. >> >> That went out the window with the arrival of MVS/370, which introduced >> SVC 99. >> > History question: Didn't DAIR, with similar function, antedate MVS/370? I assume you mean IKJDAIR. That was more limited than SVC 99, but did basic dynamic allocation quite well. It was part of the TMP and its use was limited to TSO. In those days TSO was not an address space, but simply a region within the MVT or OS/VS2 address space. It was MVS/370 that allowed any address space to perform dynamic allocation. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 17:23:18 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in <1554048328241551.wa.paulgboulderaim@listserv.ua.edu>): > On Tue, 10 Jan 2017 20:18:04 +, David W Noon wrote: [snip] >> So, saying "no code changes" is rather arbitrary. >> > New function requires new support. Changes would be needed at the > system layer such as ATTACH and OPEN; not at the application layer > such as Charles's example, FTP. But we are really discussing COBOL and its current limitation regarding dynamic DDNAME usage. Other programming languages don't have this limitation. > It's dreadfully wasteful for each application program that needs the facility > to duplicate the code to process the alternate DDNAME list. What list? I am suggesting that any DDNAME that cannot be specified at design time be made parametric. That is all that COBOL needs to handle dynamic DDNAMEs. Frank Swarbrick's message would indicate that this is in the 2014 ISO/ANSI standard for COBOL but has not yet been implemented by IBM. >> How do you know what my habits are? >> > OK, then, not habits. You make your biases disturbingly clear. > I suppose the recent U.S. political campaign established a new > standard of deportment. I don't understand this. What has the U.S. political campaign to do with me? Should I have put a smiley after what I thought was an obviously rhetorical question? >> When writing shell scripts, environment variables are inescapable as >> every shell variable is in the shell's environment. If all you write are >> shell scripts then everything looks like an environment variable. >> > There's a distinction at least in terminology. "Exported" variables are > called "environment variables"; ohers are simply called "shell variables". > The former are available in programs forked by the shell; the latter > are not. But all are visible within the script. Visibility is not the issue here. The issue that arises is that any given variable has only one instance within an address space for a COBOL (or similar, traditional) program. >> The PARM field is more akin to the argv[] strings fed into a C/C++ or >> Java program. At least COBOL allows for this to be handled in the >> LINKAGE SECTION of the DATA DIVISION. However, COBOL has not >> traditionally handled environment variables and has not really needed them. >> > You don't "really need" anything other than a Universal Turing Machine. > Higher level facilities make our jobs easier. Well, that's COBOL out the window. ... :-) >> ... Worse still, the environment >> variables are shared by all tasks in the address space, so we are back >> with the problem of dynamically providing a name to identify an >> allocated dataset. The upshot is that an environment variable of a given >> name (i.e. hard coded in the COBOL source) will be the same for all >> tasks in the address space, just like the DDNAME in the TIOT/SIOT. >> > No. spawn() with _BPX_SHAREAS=YES (an environment variable) can > support multiple processes, each with its own environment variables > and its own TCB in a single address space. This is z/OS-peculiar; > not customary over all UNIXes. > > Look at the specification of execve(): > int execve(const char *path, char *const argv[], char *const envp[]); > Simply, argv[] is a list of positional arguments; envp[] is a similar list of > keyword arguments. The caller has complete control of both. And how many COBOL programmers do you expect to use a variant of the POSIX standard API? [And how do we get them to use this with "no code changes"?] > You misunderstand the operation of _BPX_SHAREAS. Actually, I don't. It's just that we are focussed on COBOL here, and the POSIX API is not readily exploited in that language. All the languages that can readily exploit the POSIX API already have dynamic DDNAME handling. >> As coded, each calling task can choose a DDNAME, possibly returned by >> SVC99, to have the same subroutine process different datasets for >> different tasks -- possibly concurrently. >> > And where would you get the arguments to pass to SVC99? The calling program would supply the sample subroutine with a DDNAME after having done whatever SVC 99 processing might be necessary. The calling program might use an existing DD, or it could read in a DSN and use SVC 99, or any other allocation strategy one could dream up. Different callers could use different allocation strategies to allocate different datasets with different DDNAMEs, all to be processed by the same subroutine. > And how > would you preserve one of the aboriginal design obj
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 13:06:14 -0600, Paul Gilmartin
(000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: "task
level" TIOT & XTIOT? A crazy thought?" (in
<2517422968801667.wa.paulgboulderaim@listserv.ua.edu>):
[snip]
> On Tue, 10 Jan 2017 18:26:27 +, David W Noon wrote:
>>
>> Simply use PL/I with the TITLE() option on the OPEN statement. ...
>>
>> If you really are wedded to COBOL, ask for the language to offer a new
>> facility in the ENVIRONMENT DIVISION, ...
>>
> No. The facility should be transparent to the attached program (no
> code changes). Charles isn't entitled to alter FTP to meet his needs.
The existing code cannot deal with a single DDNAME being used for
multiple, distinct datasets in the same address space. The existing code
base handles its current working practices quite adequately, but new
functionality typically cannot be implemented without code changes.
So, saying "no code changes" is rather arbitrary.
>> This is far more straightforward than fiddling with multiple TIOT, SIOT,
>> DSAB, etc. This also avoids the filth known as environment variables.
>>
> Why do you call a potentially effective approach that doesn't match your
> habits "filth".
How do you know what my habits are?
> But environment variables are merely an additional PARM
> (see the specification of the exec() syscall) and no more transparent than
> the alternate DDNAME list (filth?) as a second PARM.
I am very familiar with environment variables and have been for over 25
years. That still doesn't mean I particularly like them, even in
languages used more frequently than COBOL on POSIX platforms.
When writing shell scripts, environment variables are inescapable as
every shell variable is in the shell's environment. If all you write are
shell scripts then everything looks like an environment variable.
The PARM field is more akin to the argv[] strings fed into a C/C++ or
Java program. At least COBOL allows for this to be handled in the
LINKAGE SECTION of the DATA DIVISION. However, COBOL has not
traditionally handled environment variables and has not really needed them.
I view adding environment variables to COBOL as being like putting
high-octane gasoline into a diesel engine -- it might sound "way kewl"
but the results will not be pretty. Worse still, the environment
variables are shared by all tasks in the address space, so we are back
with the problem of dynamically providing a name to identify an
allocated dataset. The upshot is that an environment variable of a given
name (i.e. hard coded in the COBOL source) will be the same for all
tasks in the address space, just like the DDNAME in the TIOT/SIOT.
> DDNAMEs seem to have had the noble objective of isolating a program
> from details of external data. In the context of concurrent processing,
> DDNAMEs "missed it by this much!"
*Hard coded* DDNAMEs missed it by this much.
The functionally richer programming languages (PL/I, assembler) have
always allowed a program to specify the DDNAME field of a DCB or ACB at
run time. This has allowed a DDNAME to be fed in from various sources at
run time.
The missing capability here is with the COBOL language, and the
extension I recommended would be a simple and effective way of adding
it, while adhering to existing coding culture in COBOL.
Since you have written in the past that you don't write assembler, I
shall infer that you don't write PL/I either. So I will offer some
sample code in C, in the hope that your love of POSIX platforms has made
you familiar with that language.
#include
#include
void read_some_text(const char * DDN, char ** text_buffer)
{
char dd_string[16];
strcpy(dd_string, "DDNAME:");
strncat(dd_string, DDN, 8): /* DD names are at most 8 bytes. */
FILE * input_file = fopen(dd_string,"rt");
/* Process file. */
. . .
fclose(input_file);
return;
}
Now, would you recommend that the above be re-coded to use an
environment variable for its DDN parameter, instead of using a program
variable as an argument? This would mean that all calling tasks within
the address space would use the same environment variable's contents to
build the parameter for fopen(), which means that all tasks would use
the same allocation of the same dataset.
As coded, each calling task can choose a DDNAME, possibly returned by
SVC99, to have the same subroutine process different datasets for
different tasks -- possibly concurrently.
I hope you now see why environment variables are not really a workable
solution for multi-tasking address spaces.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
david.w.n...@googlemail.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 12:38:22 -0600, John Mckown (john.archie.mck...@gmail.com) wrote about "Re: "task level" TIOT & XTIOT? A crazy thought?" (in <caajsdjjoucft7ticw+gkj1g2j_fgrqq7pl2ee+owrhdmtns...@mail.gmail.com>): > On Tue, Jan 10, 2017 at 12:26 PM, David W Noon < > 013a910fd252-dmarc-requ...@listserv.ua.edu> wrote: [snip] >> If you really are wedded to COBOL, ask for the language to offer a new >> facility in the ENVIRONMENT DIVISION, like: >> >> SELECT ASSIGN TO >> >> where the is something like: >> >>77WS-MY-DDNAMEPIC X(8). >> >> This can be the target of a text unit for SVC 99, or read from input, or >> passed in from a calling main program. > > Already taken, but not for WORKING STORAGE or the DD name. It can refer > to an existing DD name. If said DD does not exist, then it is the name of > the "environment variable" (UNIX concept) which contains information to do > an SVC 99. But the name remains the DD name, you can't override that, > unfortunately. That's why I said it would be a new facility in the language. The ASSIGN TO clause has always used the DDNAME, frequently decorated with hardware parameters. In recent years it can be the name of an environment variable that contains the dynalloc text for SVC 99. What I am saying is that allowing a program variable (WORKING-STORAGE or LINKAGE SECTION, or even a field in a file record) would extend COBOL to have most of the PL/I facilities of its TITLE() option or the C run-time library's fopen() call. >> This is far more straightforward than fiddling with multiple TIOT, SIOT, >> DSAB, etc. This also avoids the filth known as environment variables. I cannot stress the first sentence of the above paragraph too strongly. Adding a language facility so tightly tied to z/OS torpedoes program portability. It won't even work on z/VM, except in a z/OS guest. > too late, as stated above. Personally, I don't find environment variables > to be "filth". But I'm a long time UNIX user too. In a COBOL context, environment variables are total filth; the language has never had the syntax or semantics to handle them and has never needed them. I don't even like them that much when I am writing C/C++ or Python on a UNIX platform. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: "task level" TIOT & XTIOT? A crazy thought?
On Tue, 10 Jan 2017 07:27:12 -0600, John Mckown (john.archie.mck...@gmail.com) wrote about ""task level" TIOT & XTIOT? A crazy thought?" (in <caajsdjgawmzkmaec7ngld5wjv_yyw1h9-wo+bsdqtts1xs3...@mail.gmail.com>): [snip] > So, have you ever wanted to run multiple, concurrent, executions of some > program which does not accept an alternative DD name list? For instance, > some in-house COBOL program. Simply use PL/I with the TITLE() option on the OPEN statement. This allows the program to specify the DDNAME at run time. If you really are wedded to COBOL, ask for the language to offer a new facility in the ENVIRONMENT DIVISION, like: SELECT ASSIGN TO where the is something like: 77WS-MY-DDNAMEPIC X(8). This can be the target of a text unit for SVC 99, or read from input, or passed in from a calling main program. This is far more straightforward than fiddling with multiple TIOT, SIOT, DSAB, etc. This also avoids the filth known as environment variables. > Just running the idea up the flag pole to see who salutes. I don't really > have much else to do any more. Just waiting for the axe. The waiting can be worse than the redundancy itself. ... :-( -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER SYSIN Comments?
On Mon, 19 Dec 2016 15:07:23 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: IEBGENER SYSIN Comments?" (in <9706435750968821.wa.paulgboulderaim@listserv.ua.edu>): [snip] > On Mon, 19 Dec 2016 18:10:58 +, David W Noon wrote: >> >> The old OS/360 utilities used assembler syntax for their command input. >> This means you can put as asterisk in column 1 and you can add comments >> after the operands provided you have at least one space. >> > Alas, no; or at least no longer: I suspect they were streamlined when they were rolled into DFP. A parser to handle assembler syntax would be rather larger than a bespoke parser to handle the much smaller range of commands supported by each utility. A bit over 20 years ago, I worked with a retired IBMer who helped write the OS/360 utilities and he said they all used assembler syntax because that was the only programming language the developers knew. As the old saw goes: when all you have is a hammer, everything looks like a nail. [snip] > Is there a no-op command as an alternative? No, IEBGENER never had a no-op command. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER SYSIN Comments?
On Mon, 19 Dec 2016 11:55:15 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "IEBGENER SYSIN Comments?" (in <3749050801776756.wa.paulgboulderaim@listserv.ua.edu>): > Is there any way to insert comments in IEBGENER SYSIN? (Other > utilities?) > > I've been using the comment field in a "mostly harmless" command. The old OS/360 utilities used assembler syntax for their command input. This means you can put as asterisk in column 1 and you can add comments after the operands provided you have at least one space. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPAM
On Sat, 12 Nov 2016 19:48:05 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BPAM" (in <1151053499262553.wa.paulgboulderaim@listserv.ua.edu>): > On Sun, 13 Nov 2016 00:20:44 +, David W Noon wrote: >>>> >>>> The traditional way to do this was to use a spill file, thus: [snip] > Eventually, that spill file is written back to the PDS, incurring exactly > the same BPAM overhead as if the extended member were written > directly to the target PDS. To that add the overhead of writing and > reading the spil file. That technique loses. The problem with writing directly to the PDS is that a single DCB can maintain only 1 position for reading or writing -- and that's exclusive or. Opening a second DCB presents problems I'll address below. >> Having 2 or more DCB's open on the same PDS was a recipe for data >> corruption when at least 1 was opened for output. This is because BPAM >> uses the DS1LSTAR field of the format-1 DSCB to determine end-of-data at >> open time, but any DCB that writes to the PDS will move the end-of-data >> address without updating the DSCB and without notifying any other DCB >> operating on the same PDS. The format-1 was finally updated during the >> CLOSE macro. >> > You're trying to distract me with "at least". I agreed earlier in this thread > that no more than one PDS member can be written at a time. Let's > agree on not "at least" but "exactly". If you wish, but I have known programmers who have had 2 or more DCB's open for output/update on a single PDS. They thought it was safe because they used separate DDNAMEs. > And the reads cause no interference. Surely no read updates DS1LSTAR, > and even FIND doesn't rely on DS1LSTAR; it gets TTR from the directory > entry. But the problem arises when the output DCB expands the dataset into previously unused space, without the input DCB(s) being notified of the expansion. The members stowed by the output DCB will have TTR addresses beyond the original DS1LSTAR and will cause addressing errors on FIND or POINT macros on the input DCB(s). [snip] >> A member cannot be in discontiguous space. Thus, a member that occurs >> early in the seek addresses of a PDS cannot receive additional space on >> the end of the dataset. >> >>> I strongly doubt that PDSE stores the pages of a member contiguously, >>> which you seem to assume is the reason for the restriction. >> >> I would not be too certain about that. BPAM still has to support NOTE >> and POINT macros for random access, and these assume that each member is >> in contiguous disk space so that the seek addresses are sequential. >> > And here you are "not too certain" of what IBM directly states: > z/OS 2.2.0 > z/OS DFSMS > z/OS DFSMS Using Data Sets > Non-VSAM Access to Data Sets and UNIX Files > Processing a Partitioned Data Set Extended (PDSE) > Structure of a PDSE > Reuse of Space > > When a PDSE member is updated or replaced, it is written in the first > available space. This is either at the end of the data set or in a space > in the middle of the data set marked for reuse. This space need not be > contiguous. ... I can believe this of a load module PDSE, because the physical records are all the same size: 4096 bytes. For more general data, what happens when the physical record is too large for the first available space? Can a physical record be discontiguous? I find it difficult to contemplate a physical record being split up and spread across different parts of the dataset. How would such a record be addressed as a TTR? >> To change that would require a major re-architecture of both BPAM and >> BSAM as regards NOTE and POINT processing. This would have to be >> transparent to older code that has used NOTE and POINT for decades. It >> might be possible, but it would be a serious challenge. [snip] To offer a suggestion for the above: if IBM switched all PDSE (i.e. not just load module PDSE) processing to paging, it would require a quite thick abstraction layer to map TTR addresses used by BPAM applications into RBA for accessing a VSAM linear dataset in control interval mode, which is the way to access an LDS when not memory mapped for DIV. The reason this abstraction would be so thick would be to map any physical record into potentially discontiguous pages. There is also the problem of BPAM physical records not fitting neatly into pages; this raises the potential for record "tails" to be in pages on their own or packed into pages with parts of other physical records, possibly with those other physical records belonging to other members of the PDSE. This abstraction layer could pose a perf
Re: BPAM
On Sat, 12 Nov 2016 17:07:53 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: BPAM" (in <4952142150671732.wa.paulgboulderaim@listserv.ua.edu>): > On Sat, 12 Nov 2016 20:27:13 +, David W Noon wrote: >> >> The traditional way to do this was to use a spill file, thus: >> > (But you use the past tense. Is there a better way now?) I don't think there is a new way specific to PDSE libraries. >> OPEN (PDS,INPUT),(SPILL,OUTPUT) >> FIND PDS, >> >> loop: >> READ PDS >> WRITE SPILL >> >> end loop: >> WRITE SPILL with additional records >> > Why was it not traditional at this point simply to: >STOW SPILL,,R The spill file was usually a sequential dataset on a scratch unit, typically VIO. There was no need for the overheads of BPAM (directory management, etc.). >> CLOSE PDS,SPILL >> >> > ... and avoid the remaining code? Having 2 or more DCB's open on the same PDS was a recipe for data corruption when at least 1 was opened for output. This is because BPAM uses the DS1LSTAR field of the format-1 DSCB to determine end-of-data at open time, but any DCB that writes to the PDS will move the end-of-data address without updating the DSCB and without notifying any other DCB operating on the same PDS. The format-1 was finally updated during the CLOSE macro. >> This would not facilitate the appending of data to an existing member. >> The serialization mechanism would not provide additional space to hold >> additional records within a member. >> > That's what secondary extents are for. Not so. A member cannot be in discontiguous space. Thus, a member that occurs early in the seek addresses of a PDS cannot receive additional space on the end of the dataset. > I strongly doubt that PDSE stores the pages of a member contiguously, > which you seem to assume is the reason for the restriction. I would not be too certain about that. BPAM still has to support NOTE and POINT macros for random access, and these assume that each member is in contiguous disk space so that the seek addresses are sequential. To change that would require a major re-architecture of both BPAM and BSAM as regards NOTE and POINT processing. This would have to be transparent to older code that has used NOTE and POINT for decades. It might be possible, but it would be a serious challenge. >> If you use a STOW immediately after opening a PDS for output, you will >> create a member with no records in it. >> > Yet ISPF LMMREP, which I assume is LM's wrapper for STOW, requires a > preceding LMPUT. You would have to ask IBM about that. One possibility is that LMMREP does not perform an OPEN; it expects to have an already opened DCB in the TSO address space and for that some previous operation that will open a DCB is necessary. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BPAM
On Sat, 12 Nov 2016 12:53:40 -0600, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "BPAM" (in <6642991717618577.wa.paulgboulderaim@listserv.ua.edu>): > In a recent thread in ASSEMBLER_LIST, the OP asks if it's possible > to append to a PDS(E) member. No, because the architecture of > PDS makes this prohibitively difficult. Likewise, concurrent writing > to multiple PDS members is prohibited because of that architecture. > > But the (undisclosed) architecture of PDSE removes the second > restriction. Why not also remove the first? Clearly not all writes > to a PDSE occur at end-of-information. > > Several answers to the "append" question suggested copying > to a temporary name, appending, and at the end deleting the > original and renaming the temporary, but cautioned of a timing > window. It would seem that STOW ,,R closes that widow. > Is there any need even to specify a member name before > the STOW? The traditional way to do this was to use a spill file, thus: OPEN (PDS,INPUT),(SPILL,OUTPUT) FIND PDS, loop: READ PDS WRITE SPILL end loop: WRITE SPILL with additional records CLOSE PDS,SPILL OPEN (PDS,OUTPUT),(SPILL,INPUT) loop: READ SPILL WRITE PDS end loop: STOW PDS,,R CLOSE PDS,SPILL > And I was pleased to learn that ISPF Library Management Services > allow concurrent writing to multiple PDSE members. There's no > specific documentation of this. There needn't be; it simply works. I suspect that BPAM uses an internal ENQ/DEQ mechanism to serialize access to a PDSE. This never happened for a traditional PDS. This would not facilitate the appending of data to an existing member. The serialization mechanism would not provide additional space to hold additional records within a member. > But I stumbled on a puzzling restriction: ISPF LMMREP can not > create an empty member; it must be preceded by at least one > LMPUT, which creates a record. Is there a sound technical reason > for this, or is it the whim of a designer who couldn't imagine a > use for an empty member, therefore it should be prohibited/ > (Dog in the manger?) > > It's clearly not impossible: IEBGENER with SYSUT1-DUMMY or > ISPF Edit readily create empty members. But is specialized > processing necessary to achieve this? If you use a STOW immediately after opening a PDS for output, you will create a member with no records in it. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER REblock FB--VB
On Mon, 31 Oct 2016 20:08:29 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "Re: IEBGENER REblock FB--VB" (in <9427079226127586.wa.paulgboulderaim@listserv.ua.edu>): > On Tue, 1 Nov 2016 00:31:51 +, David W Noon wrote: [snip] >> usually name the main member it is aliasing. This is because the usual >> instructions to install one of the sort-based GENER utilities include >> renaming IEBGENER to OLDGENER. >> > Always assuming that the systems programmer followed instructions and > did ALIAS rather than copy. Well, not following instructions can cause problems down the road. If OLDGENER is not available, the sort-based driver program would not be able to revert to the original in situations where the sort-based program cannot figure out what to do. Not all of IEBGENER's functionality was replicated in newer code and, at least for SYNCGENER, the name OLDGENER was hard-coded for the fall-back option. > But DDLIST shows me ICEGENER in LPALIB and IEBGENER in LINKLIB, and > the eyecatchers leave me confident it's IEBGENER. > > It would sure be nice if IEBGENER, like HLASM, identified itself in all the > empty space in the first SYSPRINT line, even as far as PTF level. > > In some cases, IBM (I think) provides the aliases (many!): > _ IEWL1 IEWBLINK 08A0 020505 00 ANY 24 > _ IEWLDRGO1 IEWBLINK 08A0 020505 00 ANY 24 > _ IEWLF1281 HEWLKED00010688 01120E 0024 24 > _ IEWLF4401 HEWLKED00010688 01120E 0024 24 > _ IEWLF8801 HEWLKED00010688 01120E 0024 24 > _ IEWLOAD 1 IEWBLINK 08A0 020505 00 ANY 24 > _ IEWLOADI1 IEWBLINK 08A0 020505 00 ANY 24 > _ IEWLOADR1 IEWBLINK 08A0 020505 00 ANY 24 The linkage editor and binder have long had a myriad of aliases. Sensible programmers use the aliases LINKEDIT and BINDER, as needed, to build load modules of whichever format. > and even: > _ IEBGENR 1 IEBGENER A820 05000E 0024 24 > > Is this a hint that the user should code IEBGENR rather than IEBGENER to get > the site's preferred copy program? And that if the site creates an alias for > ICEGENER that alias should be IEBGENR, not IEBGENER? The IEBGENR alias appears to me to be a kluge to overcome some dodgy JCL, and adding an alias to SYS1.LINKLIB was deemed quicker than fixing the JCL. Avoid kluges. An alias should always be applied to a base member, not another alias. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBGENER REblock FB--VB
On Mon, 31 Oct 2016 15:28:23 -0500, Paul Gilmartin (000433f07816-dmarc-requ...@listserv.ua.edu) wrote about "IEBGENER REblock FB--VB" (in <5402639212763003.wa.paulgboulderaim@listserv.ua.edu>): [snip] > But can I be sure I'm using the real IEBGENER, not ICEGENER, or SYNCGENR, > or WTFGENER? Will SYSPRINT tell me? Ah! SYSPRINT doesn't tell me it's > ICEGENER, unless ICEGENER mimics IEBGENER's SYSPRINT when called as > IEBGENER. Just get a directory listing of SYS1.LINKLIB. If IEBGENER is a normal member then it will be the old OS/360 utility, otherwise it will be an alias of either ICEGENER or SYNGENER. The alias directory entry will usually name the main member it is aliasing. This is because the usual instructions to install one of the sort-based GENER utilities include renaming IEBGENER to OLDGENER. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* david.w.n...@googlemail.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
