Re: Darren seems to be alive but....
On 7 January 2014 16:37, Paul Gilmartin paulgboul...@aim.com wrote: Why is LISTSERV sending me duplicate message complaints? It's been doing this with/for/to me consistently for a number of weeks. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Spawned Address Space Control in tcsh shell
On 8 January 2014 11:47, Farley, Peter x23353 peter.far...@broadridge.com wrote: I have always felt that the parent-goes-away-leaving-the-child-running scenario was the *ix substitution for what we can do with XCTL in z/OS systems. But (as usual) that might just be my wrong-headed view of the situation. I'm not so sure. While the implementors of z/OS UNIX have done a remarkable job of fusing MVS and UNIX behaviour, there are limits. I think of UNIX exec() as the closest thing to MVS XCTL. But UNIX processes are different; the parent can do the UNIX classic fork() followed by exec() done by the new child, or the similar spawn(), in each case leaving a parent and a child. Each can do their own thing (which could include further exec()s) for as long as they like, and then either can terminate independent of the other. While there may well be signals and default behaviours to worry about, the result can be that the child runs while the parent is gone. There is nothing like this in the case of MVS TCBs. If the parent ends, the child abends. Under some circumstances the abend can be caught, but life cannot continue without the parent. TonyH. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject Unicode
On 9 January 2014 20:39, Scott Ford scott_j_f...@yahoo.com wrote: We send a data message from a pc, we encrypt it with AES128 , the message is received at the host (z/OS) decrypted then converted from ascii to ebcdic..so I am trying to figure out how to Determine what codepage the pc uses and have z/OS convert it to the proper EBCDIC codepage from ASCII. Does that help ? I'm not sure how your question relates to UNICODE. If the data on the PC (Windows, I assume) is in some encoding of UNICODE, then code pages don't really come into play. Any version of Windows can (in theory) use any UNICODE character, regardless of the country or language of installation. So there will be no difference between the way a US English Windows box encodes, say the dollar sign character and the way a French French one does. The UNICODE code point for dollar sign is U+0024, and that's that. But you also mention ASCII, which (loosely) is an 8-bit encoding. (Usually ASCII these days really means some single-byte code page such as ISO 8859-n or one of the Windows ones such as 1242.) There is no general way to convert UNICODE into EBCDIC, because no IBM EBCDIC code pages encodes all UNICODE characters. And if you are talking about single byte EBCDIC code pages such as 037 or 1047, IBM's generally encode 192 characters, vs tens of thousands in UNICODE. If your PC data is in ASCII, i.e. single byte encoding, then you have to both determine the code page in use on the PC, and the one in use on your z/OS, and then use the appropriate mapping. Such a mapping may not exist. For example, if your PC is using a Polish code page, and your z/OS a Western European one such as 1047, there are characters in each that just aren't in the other. Something will break - generally someone's name will be misspelled, or worse. Maybe you can give a short example of what data you have at each end, and what you want to happen to it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject Unicode
On 10 January 2014 13:28, John Gilmore jwgli...@gmail.com wrote: Briefly, effective rules for encoding any 'character' recognized as a Unicode one as a 'longer' UTF-8 one do not in general exist. I am most puzzled to read this. UTF-8 is what Unicode calls a transform format, and the conversion from other encodings of Unicode characters is strictly (and simply) algorithmic, and by extension, unambiguous. (In the early Unicode discussions in the 1990s, some people whose native language was not English objected to the ambiguity and even intranslatability of the English phrase transform format, but despite that, the algorithmicity remains and is definitive.) Moreover, even when they are available, my experience with them has been bad. In dealing recently with a document containing mixed English, German, Korean and Japanese text I found that the UTF-8 version was 23% longer than the UTF-16 version. That I don't doubt at all. Whether UTF-8 is a good format for storage, transmission, or manipulation of Unicode characters surely varies by context. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISGENQ REASON CODE 0404
On 10 January 2014 13:18, Jon Perryman jperr...@pacbell.net wrote: Linking a program AC(1) does not mean it runs authorized. True. It simply means it can make it's self authorized thru MODESET MODE=SUP. It's a good deal more subtle than that. Linking with AC(1) is only one possible part of getting a program running APF authorized. You must also link into an authorized library (or UNIX file), and the program must be invoked in a suitable environment. It is also quite normal for a program that is not linked with AC(1) to quite legitimately find itself running APF authorized. It's real easy to see if this is your problem. Just add MODESET MODE=SUP before the ISGENQ. Being in supervisor state is not a requirement for the ISGENQ service generally or any of its options. Regardless, supervisor state is independent of being APF authorized. To be sure, if you are in supervisor state you can eventually do anything, and if you are APF authorized, you can get into supervisor state, but they are by no means the same thing. There are many services that require at least APF authorization that do not require a supervisor state caller, and ISQENQ is one of them. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mainframe culture question - how display a tab character?
On 10 January 2014 20:09, Charles Mills charl...@mcn.org wrote: Passed parms? Is that like the cannibal who passed his friend in the woods? All the wines in this establishment have been personally passed by the proprietor. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Subject Unicode
On 12 January 2014 10:21, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: on 01/09/2014 at 09:00 PM, Tony Harminc t...@harminc.net said: There is no general way to convert UNICODE into EBCDIC, There are EBCDIC transforms for Unicode. I'm not sure whether that qulifies as EBCDIC. Exactly as much as UTF-8 qualifies as ASCII, that is to say, not at all. In both cases (UTF-8 and UTF-EBCDIC), there are several characteristics of the encoded result that are convenient in the respective environments. In particular, for legacy applications, the most often used characters in single-byte ASCII/EBCDIC are encoded by the same byte value in UTF-xxx. But no one would say that UTF-8 *is* ASCII, or that UTF-EBCDIC *is* EBCDIC. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RUN detaches the TSO TEST/TESTAUTH TCB
On 15 January 2014 13:44, Micheal Butz michealb...@optonline.net wrote: From the doc it seems run detaches the TSO test TCB so PSATOLD is valid correct ? PSATOLD is always valid if you are running under a TCB. If you use a TEST command to look at PSATOLD, you will see the address of a TEST TCB, but this is not wrong or invalid. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 21 January 2014 13:39, John McKown john.archie.mck...@gmail.com wrote: This is a curiosity question. I am wondering how resistant shops are to even having the Java JDK installed on their system. Not in being resistant to writing application code in Java, but just to having it available. In particular, are there many shops who would reject a useful product because it was written in Java versus in C, C++, or some other language? Two quite separate questions, since you can do all your compiles on the desktop or wherever, and just run on the z. I don't work at a z production shop, so regardless, I have no idea what the answers are. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22 January 2014 08:36, John McKown john.archie.mck...@gmail.com wrote: Now wouldn't that be a kick? An Enterprise COBOL compatible compiler which produced Java byte code. That would likely sell a lot of zAAPs. Don't think it hasn't been seriously considered by more than one party... But as with any number of other such approaches, it would be limited by its own success. If it managed to displace any significant amount of IBM revenue by shifting legacy workloads to cheaper processors, IBM would put a stop to it, either technically or by new Ts Cs of some sort. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Resistance to Java.
On 22 January 2014 19:34, John McKown john.archie.mck...@gmail.com wrote: I'm going to look at that. Not for z/OS use, but for me on my Linux/Intel system. On Wed, Jan 22, 2014 at 5:22 PM, Graham Harris harris...@gmail.com wrote: http://sourceforge.net/projects/universalcobol/ As it says on that page, dated five years ago, Initial checkin. It all appears to compile, but doesn't run at the moment. Not to say it mightn't be fun to play with. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: P[ro]Ops and Infocenter?
On 22 January 2014 21:00, Paul Gilmartin paulgboul...@aim.com wrote: Is/are the P[ro]Ops available via Infocenter? Or is Infocenter software only? I'd rather have a web interface to a current copy than several PDFs of varying age on the several desktops I use. I haven't seen it on the Infocenter, but who knows - maybe it'll come. The IBM i has the opposite problem: the closest thing to a P[ro]Ops that exists for that box (the MI reference) used to be available in PDF, but is now only on the InfoCenter in a very difficult to use form. Well, wouldn't want anyone easily using low-level techniques or understanding how things work, would we now? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TSO/E Reconnect
On 22 January 2014 21:09, Paul Gilmartin paulgboul...@aim.com wrote: A coworker has observed that if he connects to TSO/E via VTAM then disconnects (pulls the plug; not logs out), he can reconnect. If he connects via tn3270 and attempts to reconnect, he gets a new session. What do you mean by via VTAM? Is your colleague using a real 3270 device? If not, what, and how is it connected? I can reproduce this. Furthermore, if I logon initially with VTAM, then pull the plug, I can reconnect to the running session with tn3270, absent VTAM. What makes the difference? We'd like to spare the overhead of running VTAM on a separate (VM, in this case) host. Ah - I suspect you mean that you are using virtual local 3270s provided by VM. Regardless, you can't connect to TSO without VTAM (or conceivably TCAM!); there is no direct TCP/IP to TSO connection. You need VTAM and TCAS in the loop, unless IBM has slipped a big change past me recently. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM sells x86 server business to Lenovo (was Levono)
On 23 January 2014 12:43, Charles Mills charl...@mcn.org wrote: I think IBM's core business is (1) services and (2) software. I don't think IBM has been in the core business since the early 1970s. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IFL z/VM
On 28 January 2014 12:57, JT jethin...@aol.com wrote: From my manager. Is it possible to run CICS (executing COBOL application code) on an IFL? Short answer: no. The only OSs that IBM supports IPLing on an IFL are Linux and zVM. But even under either of these, IBM will not license you a version of CICS that will run on an IFL. Whether you can run your own COBOL programs on one, I don't know. Probably IBM will not license the COBOL run time (LE) to run there. You might be able to use a very old public-domain COBOL compiler, but then it wouldn't talk to the CICS that you can't run anyway. So really, no. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions (try this)
On 29 January 2014 11:35, Ted MacNEIL tedmacn...@bell.blackberry.net wrote: I truly believe that one ID per person with the ability to sign on once per LPAR (and share the same ISPPROF) is simpler to implement. No doubt. But simpler to implement may not be at the top of everyone's list. I don't believe that the typical user needs multiple userids to do their job. Unfortunately you sound like the IT guy when you say something like that, and the IT guy is probably at least as low on the pole as the cable guy. http://dilbert.com/strips/comic/2007-11-16/ Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: multiple TSO Sessions
On 29 January 2014 17:19, Paul Gilmartin paulgboul...@aim.com wrote: think there was also a problem with the TIOC sending command output to the wrong terminal. I.e. enter the LISTALC command on terminal#1 and the results might go to terminal#2 instead. But I'm real vague on that last one. I can do that right now. From a Unix System services, I issue Rexx address TSO hmigrate DATA.SET.NAME and watch messages appearing on my 3270 TSO session. Sure, but that's a rather different and far less unreasonable problem. What does UNIX do in general when you send a message to a user by userid? Send it to all sessions, or the first, or a random one, or...? I'll be quite surprised to find the TIOC using only the userid as a key to keep track of where to send non cross-memory TPUTs. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESGB400/IEFGB400
On 3 February 2014 14:24, SUBSCRIBE IBM-MAIN Harold Gray harold.g...@mantissa.com wrote: [...] L R3,JESCTEXTLOAD PAGEABLE EXTENTION DROP R3 USING JESPEXT,R3 EST ADDRESSABILITY WITH EXT L R4,JESGB400GET MSG WRITER ADDRESS * This code has been working since the 1990's. The linkages still are valid but the routine does not appear to be executed anymore. I've looked for any notes in the migration doc's and I've compared the macro (JESCT) that describes the aplicable areas and have not detected anything that would account for what happened. It's not looking good... The JESCT description in the 1.13 data areas doesn't list JESPEXT as a PI field. And the z/OS 2.1 book that claims to contain JESCT seems to be truncated after IXLYEEPL. :-( Neither does the JES2 source or maclib contain the strings JESGB400 or IEFGB400. I can't find any reference to either name in any of the current z/OS doc. So I would guess that IBM has quietly stopped using this interface, since it seems not to have been documented for a long time. But you'd need to ask IBM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: JESGB400/IEFGB400
On 4 February 2014 19:12, Ed Jaffe edja...@phoenixsoftware.com wrote: On 2/4/2014 3:51 PM, SUBSCRIBE IBM-MAIN Harold Gray wrote: I'm coming to that conclusion also. I can't seem to get the 2.1 data areas vol 4 (JESCT) to download the whole book so I'll have to wait and try it again later. Both pointers are present in the z/OS 2.1 version of IEFJESCT. Sure, but the OP says the routine doesn't seem to be getting called. And they are certainly not GUPI, or even anything-PI. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On 12 February 2014 14:21, Jim Mulder d10j...@us.ibm.com wrote: When a length of 0 is requested on GETMAIN or STORAGE OBTAIN, VSM treats this as a successful request, and returns an address of 0. In my opinion, this was a poor design choice, made long before my time, and I have seen it lead to diagnosis confusion like this several times over the years. I would have preferred to abend when a length of 0 is requested. But it has worked this way since at least MVS/370, and maybe even long before that, so for compatibility reasons, we do not change it. I object far more to returning an address of 0 than to accepting a length of 0 on the request. To be sure, you are allowed to store no more than 0 bytes in your obtained area, so the 0 address sounds reasonable, but some instructions are allowed by the architecture to recognize access exceptions in the case where no data is stored, e.g. STCM with a zero mask. So to be consistent, a non-zero address with appropriate access setup (primarily key) should probably be returned. Now if you ask me how I would prioritize this requirement... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On 12 February 2014 18:22, Gerhard Postpischil gerha...@charter.net wrote: On 2/12/2014 6:06 PM, Tony Harminc wrote: I object far more to returning an address of 0 than to accepting a length of 0 on the request. To be sure, you are allowed to store no more than 0 bytes in your obtained area, so the 0 address sounds reasonable, but some instructions are allowed by the architecture to recognize access exceptions in the case where no data is stored, e.g. STCM with a zero mask. The way I get and free storage, I'd be happier with an abend (R form) or non-zero return code. Sure, but as said, that's not going to happen for reasons of compatibility. I generally save the length, and then do a FREEMAIN (or STORAGE RELEASE) using the saved length. If the GETMAIN/OBTAIN was accepted, freeing zero length is an instant disaster. You can't free 0 bytes at address 0? Now that is an inconsistency. Ah - the subpool thing on FREEMAIN. Is that also true for STORAGE RELEASE? So to be consistent, a non-zero address with appropriate access setup (primarily key) should probably be returned. Consistent with what? It can't return an address because one wasn't assigned. Sure - it could assign one. It wouldn't have to be unique; just access-exception correct. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Storage Obtain .....
On 12 February 2014 20:07, Charles Mills charl...@mcn.org wrote: Sure - it could assign one. It wouldn't have to be unique; just access-exception correct. And then the OP would have cleared that dummy storage area passed back from OBTAIN and wondered how _that_ happened. If you clear only your requested 0 bytes of the area, all should be well. MVCL and friends would work fine for that. I don't see how IBM solves it without creating a nightmare for some number of programs that do this. That clear more storage than they requested? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Branch (was: Performance question - adding)
On 17 February 2014 09:37, John McKown john.archie.mck...@gmail.com wrote: LT R0,CURRENT #LOAD CURRENT AND SET CC SPM R1 #SAVE CC FROM LT A R0,SUM #ADD SUM TO IT IPM R1 #RESTORE CC FROM LT STOC R0,SUM,NZ #STORE SUM ONLY IF CC OF LT WAS NZ Basically this loads CURRENT into R0, setting the CC based on its value. Then saves the CC in R1. Adds the SUM value into R0. Restores the CC from the LT, because the Add destroyed it. Then only stores the result in SUM if the CC is Not Zero, as set by the LT. Not that it affects your proposal, but I think your SPM and IPM are reversed there... It's perhaps interesting that IPM appeared only in 370/XA; on 24-bit systems BALR was expected to do. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Question about z/OS v2.1 stability
On 18 February 2014 11:47, Miklos Szigetvari miklos.szigetv...@isis-papyrus.com wrote: We have here serious problems with the v2.1 C/C++ compiler, the generated machine code largely differs from 1.13, and with some serious errors (till now) Do these problems go with the compiler itself, or with the TARGET and OPTIMIZE levels you are specifying (or defaulting)? Or, put another way, does specifying lower levels for these avoid the problems? Any information on these problems you can post here will be welcome. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: assembler
On 19 February 2014 11:12, DASDBILL2 dasdbi...@comcast.net wrote: So what was the correct term for non-virtual storage way back then for non-67 models of the S/360? Storage? Real storage? V=R storage? The terms I heard most frequently included the word core. In my circles the term core survived for quite a long time after the introduction of the first 370 models with non magnetic-core storage (the 158 and 168, followed closely by the lower end 138, 148 and so on). And amusingly the UNIX people still use core in some contexts, much as they use print in a way long dissociated from ink on paper. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On 18 February 2014 18:39, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: on 02/18/2014 at 01:47 PM, Tony Harminc t...@harminc.net said: Indeed this is the way conditional execution and branching works (and has always worked) in channel programs. No. No what? Every generation believes that it invented sex, I think we need a counter for your yearly use of this cliché, and another for the PKBs. But will a halfword be big enough...? but the S/360 was not the first boy on the block. The business with Status Modifier came in with S/360, but there were conditional branches in channel programs before that. I didn't suggest, let alone say, anything counter to this. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT - What is the proper term for K notation?
On 2 May 2013 14:31, John Gilmore jwgli...@gmail.com wrote: Strictly speaking nude values like 1.234K are not well formed. They specify a magnitude but not a unit, kilobyte or kibibyte, kilocalorie or kibicalorie, kilogram or kibigram, kilometer or kibimeter, etc., etc. To the question 'If I had integers 1234 and 456, what would you call it if they were formatted as 1.234K and 4.56M?', I was about to say broken or wrong. But nude expresses the notation and its problem perfectly, and I recommend it with only a small :-) needed. To 'OTOH, what would be the contrasting term for normal notation: 1234 and 456?', I would say simply decimal, though that of course runs the risk of being taken as being in opposition to binary or hexadecimal (or any number of other less likely bases). There are two other aspects that may bear thinking about: The letters K and M are not universally understood to be either of (10**3 and 10**6) or (2**10 and 2**20). In particular, financial people and executive types to this day often use M to mean thousand, and use MM for million. Doubtless these derive from Roman numerals (though MM would be 2000), but like the Romans they are not quite dead yet, and if it really matters you should probably avoid them.* If you want names for your notations, you should consider also precision and rounding. Perhaps your program will just do what it perceives to be the sensible thing, but once you give users the choice by some keyword of 1.234K vs 1234, when should they expect 1.2340K vs 1.23K or even 1K? Tony H. * There are actually three overlapping and incompatible schemes used for money: that used by accountants and other money men, that used by engineers and other technical people, and that used by tabloid newspapers in headlines: SI Financial TabloidMultiplier k (kilo)M (Roman) G (grand) 10**3 M (mega)MM (Roman) M (million)10**6 G (giga)MMM (rare) B (billion)10**9 T (tera)- Tr (trillion) 10**12 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Return codes
On 8 May 2013 16:59, Pew, Curtis G curtis@austin.utexas.edu wrote: On May 8, 2013, at 3:50 PM, John Gilmore jwgli...@gmail.com wrote: Your sort of B/T has important uses, but one composed only of addresses is useful too. Perhaps it shoul;d be called an address table to avoid confusion. I will; send you an example privately. If you have a table with 8 byte addresses you can still use the multiple-of-4 return code convention, just shift left one bit before using it as an index. By the same token, you can have multiple-of-1 (i.e. arbitrary positive integer - is there a better name?) return codes, and shift left by 2 or 3 bits as appropriate. But it may be that the existing convention to some extent discourages very sparse return code domains, which makes the branch or address table scheme largely unusable. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Destination z -- Back to the Future -- Don't Reinvent Mainframe Wheels
On 15 May 2013 14:08, John McKown john.archie.mck...@gmail.com wrote: Yeah, well I didn't say it was a _good_ idea grin/. Actually, if the epoch were moved BACK in time, then the TOD value would need to be increased to keep the date the same. Which is just what happened with MVT and MVS; the epoch was changed from 1960 to 1900. Though there was, of course, nothing much to force anyone to use either the old or the new IBM standard. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Mysterious Abend 0C1
On 22 May 2013 12:39, Ed Jaffe edja...@phoenixsoftware.com wrote: On 5/22/2013 8:34 AM, Elardus Engelbrecht wrote: Of course, the OP discovered later that 'dump analyser picked up the wrong PSW '. This is why I stopped using all dump analyzers (other than my own brain) over two decades ago! It's not obvious that dump analyser meant a program as opposed to a person. I'd much rather find the PSW and registers myself--starting with SYSTRACE and working from there. But then you're trusting IPCS (presumably) to format the trace entries correctly. Something it has been known to silently get wrong, if there is a version mismatch between IPCS and dump. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Gives There a VM Discussion List?
On 4 June 2013 11:31, Steve Thompson sthomp...@us.ibm.com wrote: What I am looking for is an equivalent to IBM Main for VM/CMS. Well... There's nothing to say that VM topics shouldn't be discussed on IBM-MAIN. Certainly most of the discussion is closely related to z/OS, but this list is not restricted to that one OS. That said, if you want VM-only discussions, try the IBMVM list at uark. You should be able to subscribe directly from the list's web page at http://listserv.uark.edu/cgi-bin/wa?A0=ibmvm Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Anyone familiar with how z/OS CSRCESRV works?
On 10 June 2013 19:58, Charles Mills charl...@mcn.org wrote: Is anyone familiar with the internals of CSRCESRV run-length compression? I am familiar with RLE schemes in general -- typically a run of n identical characters is replaced with something like escapencharacter. Does anyone know the specifics of z/OS's scheme? What is the escape character? How is n specified? Is it escapencharacter or escapecharactern. How do they handle occurrences of escape in the original data? (A typical scheme is escape1escape.) I don't know, but without looking I'd guess it's SNA Character String (SCS) format, or perhaps part of it. The first byte would be a String Control Byte (SCB), with the leftmost two bits indicating what follows, and the rightmost six containing the length of the run of data. Of course there might well be higher level header info. 00 cc No compressed characters follow 10 cc Repeat blanks 11 cc Repeat the following non-blank character 01 cc Compacted characters follow The above is from the NJE Formats Protocols book, but it's documented in lots of places, including non-mainframe ones. It should be pretty easy to check my guess against your data - certainly if you have raw and compressed data to compare. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reader Comment on SA22-7832-08 (PoPS), should I?
On 27 June 2013 11:48, John McKown john.archie.mck...@gmail.com wrote: Would it be worth while to tell IBM that the document would be much more readable if it were like the other manuals; having only one column of text, except perhaps for tables? I have had nothing but good results from my RCFs to the PrOps over the years. Those have all been regarding technical matters rather than formatting, but by all means do send in your comments. I'm sure they will be quite receptive. I wonder if it would be worth my while to try to OCR the PDF to create something that I could import into a true DTP program (and I'm not talking MS Word! Perhaps LaTex). OCRing shouldn't be necessary. The PDF contains the text already (as evidenced by the correct working of the find function) and should be editable in any PDF editor. There are no security flags set that would prevent this, but I don't know what the copyright implications of doing so might be. This is almost certainly not the right forum to get into (yet another, usually ill-informed) discussion of the copyright laws. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: What programmer's fear (not IBM specific)
On 5 July 2013 03:06, David Crayford dcrayf...@gmail.com wrote: On 5/07/2013 2:56 PM, Martin Packer wrote: If that's true in Another World I wonder what it'd take to make it true in THIS one. For a start somebody to port OOREXX to z/OS. That's not going to happen until somebody first ports a recent version of GNU autotools. That's not going to happen until at least z/OS 2.10 when the new GNU extended streams API is available. We may be waiting a while... The EBCDIC stuff in OOREXX is mostly complete. I did that years ago. I bailed when it became clear that fixing the build system was an intractable problem. Is it not feasible to build on some other system with a cross compiler for zArch? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: COBOL was: COBOL Parser
On 19 July 2013 08:19, John Gilmore jwgli...@gmail.com wrote: Some all but random responses. [...] The C language switch statement is defined very specifically and carefully as an SBCS single-character facility. Not at all incidentally, this definition ensures that branch tables can always be used to implement a C switch statement. One can argue that in the highly constrained hardware environments where C grew up, a 256-byte branch table was far more of a barely thinkable extravagance than is a 64k one today. I would not be at all surprised to learn of some PDP-11 architectural construct that makes restricting switch statements to single byte values desirable for implementation purposes independent of the ability to use branch tables. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: zBC12 article on one of my PC sites!
On 23 July 2013 11:56, John McKown john.archie.mck...@gmail.com wrote: http://arstechnica.com/information-technology/2013/07/ibm-unveils-new-mainframe-for-the-rest-of-us/ Not a lot in it, but some $ figures. quote And as far as mainframes go, the zBC12 is priced to move, starting at $75,000—or for lease starting at $1,965 a month. That’s roughly half the cost of buying the equivalent computing power in commodity x86 hardware. /quote I think I hear Lynn typing... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center
On 24 July 2013 10:05, Lizette Koehler stars...@mindspring.com wrote: But as someone else pointed out, there might be copyright issues with printing companies like Kinko. Indeed I had an order refused a few years ago by a big name printing place; they wanted a statement of copyright permission. IBM does provide one, but I didn't have it handy, so I just went to the nearby ma and pa printing place who was happy to do it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: The Rubicon has been crossed: no more hardcopy IBM publications from the IBM Publications Center
On 23 July 2013 17:21, John Gilmore jwgli...@gmail.com wrote: begin copy Effective July 29th 2013: According to e-Business strategy, IBM Publications Center does'nt support ordering anymore. The Publications are being made available in electronic format to be viewed or downloaded free of charge. /end copy If you judge that you need a hardcopy version of a manual, order it during the next few days. Heh... I've been trying for some weeks to order a couple of sets of SC33-0604-00 APL/2 Keyboard Stickers. I don't relish printing these onto sticky labels from a PDF, and then cutting them out by hand! In any case the pubs centre no longer takes credit cards; one must have a customer number. Well I have one (my own - not my employer's) from the 1990s that I used to order the then popular OS/2 books. So I submitted my order using their bizarre scheme that requires that one generate a pseudo-random order key for reference, according to rules which are enforced quite differently from those documented. All seemed OK, and I was promptly emailed a note saying that my order would be reviewed and returned to me for final approval. Nothing for two weeks, so I went to their check order status page, entered my order number and key, and was promptly redirected to a non-existent URL. (Well, an entire non-existent server lw-sit01.linux.ehone.ibm.com). I submitted a feedback form (at least that worked), and got a short, sharp email (possibly from a human) telling me that my customer number was invalid, and to resubmit with a correct one. No help offered, no attempt to look up my company's or my name, no phone call. So I suspect that they knew at the time that if they could just delay me by a few weeks, their problems would be over. Still, there remains the issue that certain pubs are almost inherently hardcopy. There are stickers, slides, microfiche, etc. still in theory extant that just won't do as downloadables. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there a TSS mailing list?
On 9 August 2013 12:32, Ken Porowski ken.porow...@cit.com wrote: Last message I got was in 2011 There was one topic in March 2013, and about 15 separate topics in 2012, so it's perhaps not quite as dead as that. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database protection
On 17 August 2013 13:54, Walt Farrell walt.farr...@gmail.com wrote: Where possible, you can switch to the use of password phrases rather than passwords. You're right that the brute fore attacks are increasingly simple for mere 8-byte passwords, but password phrases give you longer values (minimum 14 by default, though you can decrease that to 9 with an exit) that will be harder. And with commonly available technology it's perhaps impossible today if you have only a slightly longer string. It would be a better idea if IBM didn't require (on z/OS RACF) that all userids continue to have a password! Why would an attacker bother to attack the phrase when there is certain to be a short password with a very restricted character set to attack? Of course you can write a program to set the encrypted password to a value that is not the result of encrypting a userid with a valid password. We put this into our password synch/reset product primarily to make it easy to set things up so a user with a phrase can have a password that isn't known to the administrator or the user, but it has the additional advantage of enlarging the domain of things to attack by brute force methods. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
On 21 August 2013 14:59, Richard Pinion rpin...@netscape.com wrote: A data set is compressed using TRSMAIN on z/OS. It is transmitted, using binary format, to a non-z/OS server. For whatever reason the compressed file on the server is incomplete. When the compressed file is transmitted, using binary format, back to a z/OS system, and uncompressed, will TRSMAIN know the data set is incomplete? Depends on what you mean by incomplete. A TRSMAIN/AMATERSE compressed data stream consists of a short header, and then 12-bit units with a value from 1 to 4096, terminated by a unit of zeros. The header does not contain an overall length field. (There is also a trailer, but I'm not sure it's used for anything.) If decompression hits EOF before seeing that ending zero unit, it should complain, though I don't know how elegantly. So if your data is truncated, it can and should be detected. But if you restore your damaged data into an FB dataset, the last block may be zero padded regardless, so a silent failure seems quite possible. If your compressed stream is missing a chunk in the middle, it's possible - and with anything bigger than a very small dataset, even likely - that what remains is decodable, but after the gap it certainly won't decode into anything much like the original. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: TRSMAIN
On 21 August 2013 20:39, Barry Merrill ba...@mxg.com wrote: It's an easy JCL exercise to conduct an experiment to confirm what happens: TRSMAIN/AMATERSE will read a truncated tersed file and never detect it was truncated. I copied a 105472 byte valid tersed file into a DISP=(,CATLG,CATLG),SPACE=(TRK,(1)). The original untersed to 360,480 bytes, while the truncated file untersed to only 48152, and there was no message nor warning that the input file was short. Can you look at the last record in the truncated tersed dataset and see if it's zero-padded? Strictly one should look for a 12-bit zero, but a run of three of the 8-bit kind we're more used to would more than do the trick. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SMS Notices from Jes2
On 27 August 2013 11:29, Sambataro, Anthony (NIH/NBS) [E] anthony.sambat...@nih.gov wrote: I've done it via the SMTP server/address space with the TO: address being the service provider's convention. For example ATT's convention is x...@txt.att.net where xxx is the 10 digit phone number. You need to be wary of using those email to SMS services provided by the carriers. For one thing, a user may change their carrier, and then the messages will (probably) fail silently. But more important, such an email isn't just a simple SMS. Many carriers require that the recipient register to receive them (to avoid traditional email spammers, and those who target phone_num...@carrier.com), and some carriers even send an actual SMS saying you have been sent an email - go to this website to read it! There are SMS service providers who will allow you to use HTML or other protocols to send real SMSs to just about any phone in the world, with various SLAs and reporting. They aren't free, of course, but neither are they expensive - at most a few cents for each message, and down to around one cent in bulk. Typically they want you to prepay by credit card, but for an enterprise customer some of them will deal on more normal commercial terms. If you can use TCP/IP from your z/OS to the outside world, you can probably write something in REXX or the like that will deal with the provider. Then you just need to trigger it from the appropriate JES2 exit. There are many of these providers out there, with varying reputations. Obviously you don't want to sign up with one that specializes in SMS marketing (spamming), or in certain countries where you have no users, so do your research. Google SMS gateway service provider to get started. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNIT=SEP still alive (?)
On 29 August 2013 16:18, R.S. r.skoru...@bremultibank.com.pl wrote: I just found the following in some IBM same JCL (job, actually): //SYSUT1 DD UNIT=(SYSDA,SEP=(SORTLIB,SYSLMOD,SYSLIN)), // SPACE=(1000,(60,20)) Last change date is half of the 2013 (creation date is probably 2005 or so). As far as I know SEP is syntax checked and ignored for many moons, at least since first OS/390, but I vaguely remember somebody told me it was obsoleted with advent of MVS. I slightly more than vaguely remember it the same way. SEP= disappeared (was ignored) with MVS, i.e. OS/VS2 2.0, because it limited the then-new SRM's ability to swap a job in or out to control the I/O workload on a channel. There is an element of conflict between the application programmer/job owner's wish to have the best possible performance for an individual job by spreading its I/O around, vs the SRM's wish to control overall system performance as specified by the performance group definitions. Swapping out or in a job with allocations all over the place would not predictably change the load on an over or under busy channel. And on that note, I even more vaguely remember that SEP= (in pre-MVS OSs) was done at the channel level rather then the device, but that's so vague as to be unreliable. Since the source code for MVT and MVS 3.8 are both available online, anyone sufficiently interested can read the code and report back. On the matter of a recent piece of JCL containing these obsolete keywords, well that is all too common. There is a widespread and hard to break culture consisting of some blend of if it ain't broke, don't fix it, I'll just copy this JCL that works and change it minimally to suit my needs, and we're not really sure we need this anymore, but I don't want to be the one to remove it and find it breaks something important, so I'd better leave it in. I removed SEP= from one of our product manuals and around 2000, and when we acquired another product almost ten years later, I found its install manual to have SEP= too. I may yet have missed some... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database protection
On 3 September 2013 09:41, Costin Enache e_cos...@yahoo.com wrote: The phrase clear text is already padded with spaces to a multiple of 8, but, after encryption, the resulting hash is truncated to the length of the original clear text, minus the padding. This leaves us with an incomplete DES cipher text block at the end, if the last clear-text block was padded. This means that, if for example the last block had one character (say 1=F1) padded to a length of 8 with spaces (F14040.), only the first byte of the resulting DES cipher text will be stored. There are many clear-texts what will generate the same byte on the first position when encrypted with DES. Example: create user COSTIN with phrase Abcd1234Abcd1234a, then try to logon with phrase Abcd1234Abcd1234X I would think that should be APARable... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNIT=SEP still alive (?)
On 3 September 2013 09:33, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: In 6708946340357622.wa.paulgboulderaim@listserv.ua.edu, on 09/02/2013 at 05:13 PM, Paul Gilmartin paulgboul...@aim.com said: And what's the TU corresponding to PASS? DALNDISP (0005) and DALCDISP (0006)with value X'02' is close. PASS is intended for multi-step jobs, and TSO sessions are supposed to be single step. But Dynalloc did not exist until MVS, and MVS has never restricted its use to TSO. So why should TSO environmental restrictions have anything to do with Dynalloc? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RACF Database protection
On 4 September 2013 04:07, Costin Enache e_cos...@yahoo.com wrote: It may not be APARable. Even if you fix the bug, what do you do with the old password phrases? Maybe update the RACF database with a secure hash value once the user logs in (to add the previously discarded hash bytes), but the system cannot know if the correct password phrase has been used (and not one of the others which also work). Or just invalidate the old phrases. The system does not store enough hash bytes to decide which password is the correct one ... in any case it would be a mess. The bug cannot be used to brute-force authentication (the account will be locked before one can benefit from the collisions) and, in case the RACF db is exposed, it is easy to crack the hashes anyway, the collisions are not really needed. It will probably just stay as it is :) Not all APARs are opened for what seems to be their obvious reason. It may well be that, with nothing beyond reported weaknesses in phrase handling, there is nothing to APAR - even more the case if it is based on reports from a third party's analysis rather than a customer's business problem. But an easily demonstrable error (accepting the wrong phrase and allowing logon) is blatant enough to perhaps get action, and if the necessary action is to redesign the whole scheme (or provide for customer/ISV supplied encryption routines, as is done for passwords), then they might just do it. I'm sure it's not that the IBM developers don't want to fix it; it's a matter of IBM management devoting sufficient time and budget to it. And that requires a customer squeaky wheel. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNIT=SEP still alive (?)
On 4 September 2013 09:41, Shmuel Metz (Seymour J.) shmuel+...@patriot.net wrote: But Dynalloc did not exist until MVS, Not as a supported facility for user code, but it was there for use by DAIR in TSO. As I recall, the interface was different. There was an SVC 99 in MVT, but it wasn't dynalloc; it was a TSO-only service routine between DAIR and DADSM and such, with a completely different parameter list and return values, and much less function. (Some Dynalloc functions were done in DAIR itself without calling the old SVC 99, e.g. allocation information retrieval.) A Dynalloc SVC 99 invocation requires that the high bit of R1 be on to show that it's the new format. Nowadays I believe SVC 99, when called with the DAIR-type list, builds a modern Dynalloc list and falls into Dynalloc processing. Since it was allowable to link-edit DAIR into one's program, this calling format is in theory supported forever. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pre-assigned/invariantASIDs?
On 6 September 2013 15:39, Gord Tomlin gt.ibm.li...@actionsoftware.com wrote: The IPCS listing in that manual is just a sample, and I would not treat it as a guarantee that the ASIDs listed there will always be the ASIDs for the indicated address spaces. In fact, they differ from what I see on a z/OS system here. I like your solid jello analogy, but the jello becomes liquid well before x'1E'! I suspect that IBM's efforts at increasing parallelism in the IPL process have reduced the number of ASIDs that can be considered invariant. And it's probably time for a cautionary note from someone at IBM, rightly stating that relying on an ASID value is not an intended programming interface. I'm curious about why you would want or need to know anything about hard-coded ASIDs. What aspect of an application or even system program makes it impossible to look up what it needs? (I realize you didn't say you needed to do this, but something surely prompted your question.) Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GETMAIN and LOC=(xx,64)
On 6 September 2013 16:53, Gerhard Postpischil gerh...@valley.net wrote: On 9/6/2013 1:52 PM, Manfred Lotz wrote: I'm maintaining a larger program written in assembler where GETMAINs have mostly LOC=(BELOW,ANY) or LOC=(ANY,ANY). This program doesn't use anything like PGSER, EXCPVR or the like. My question: In order to give the operating system most flexibility wouldn't it be recommended to change: LOC=(BELOW,ANY) --- LOC=(24,64) LOC=(ANY,ANY)--- LOC=(31,64) Any opinion appreciated. You need to verify that nothing in a relocated area uses 3-byte address constants, and that the address of the acquired storage isn't treated as 24-bit anywhere. You can either run with PRINT ON,GEN,DATA and go through the listing line by line, or change everything and hope you get an 0C4 on all bad references. Surely Manfred is just asking about the real storage that backs the virtual. Which, except in rare cases such as using EXCPVR or LRA or perhaps some fast-path VTAM operations, is entirely transparent to the application program. I see no problem with the proposed changes, and they should indeed provide some added flexibility to RSM. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 1403 Printer components manual GA24-3073-3
On 11 September 2013 15:03, John McKown john.archie.mck...@gmail.com wrote: Also, on DOS, I remember some sort of command the operator could issue to open it. I don't remember what the CCW was called, perhaps open gate? The handy S/370 yellow card on my desk (the March 1974 version) shows the 3211 having a Raise Cover CCW opcode 6B. This to some extent confirms my memory that the 1403 raised its cover only under operator command or running out of paper. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 13 September 2013 15:14, Charles Mills charl...@mcn.org wrote: Okay! Dave, can you find any Enterprise COBOL 5.1 shelf for Softcopy Librarian? I did a little poking around, since it wasn't obvious where Softcopy Librarian was getting its info. You set up an Internet source such as http://publib.boulder.ibm.com (I can't remember if SR comes with this built in, or if I got it from somewhere else, but I think the former.) So when you click on it, SL does an HTML GET for /epubs/df/ebrscrt.des on that site. This file contains a barely structured list of filenames and comments, and *that* is where that Sep 2012 string on the z/OS V1R13 and Software Products Collection PDF/BookMgr comes from. Evidently no one changed the comment, even though the file dates are 13 Sept 2013. So the file for this Collection is /epubs/df/zosv1r13.des, and that, despite the same .des filetype, contains a much more structured - though not XML - list of .bks, .xks, .boo and .pdf files, and some other metadata. You can see these in a browser, but unfortunately the directories containing the files (/epubs/book, /epubs/pdf, and /epubs/bkshelf) are not listable. Now looking at the page http://www-01.ibm.com/support/docview.wss?uid=swg27036733 that was mentioned for COBOL, the PDF files are on the very same publib.boulder.ibm.com server as the SL files. So all it would take would be for someone at IBM pubs (if there's anyone left), to edit the file zosv1r13.des and insert six PDF filenames for COBOL. Or they could do it right and actually create a .xks bookshelf file as well; even Softcopy Reader can do that. As for whether there's any way to fake this by putting your own descriptor files somewhere, well perhaps, if you have a local web server that can serve the /epubs/df directory locally, and redirect all others to the IBM site. Or perhaps you could use the proxy support in SL to redirect selectively. But then you'd still need to know the filenames, and by the time you've done that you might as well do it all (heh) manually. Friday Fun. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 16 September 2013 11:36, John Gilmore jwgli...@gmail.com wrote: Kevin is right. All of the COBOL 5.1 publications are available for downloading at the IBM Publications website. Thus, for example, the new Language Reference, SC4-7381-00, and the new Programming Guide, SC4-7382-00, are both available. Unfortunately, however, they are available there ONLY as PDFs; and the OP wanted them as Softcopy Librarian documents. He clarified in a later post that he wanted to be able to download using Softcopy Librarian, but had no objection to PDFs. And indeed SL is quite handy for not just downloading, but for its ability to compare what you have downloaded (installed) with what's available, and making it easy to update. Looked at another way, PDFs *are* Softcopy Librarian documents. Over the years I have noted that IBM-MAIN people use this site less than they should. Its facilities for searching on partial titles, single words, and the like are unexcelled. Searching on just 'COBOL 5.1', for example, yielded the titles and a download box for all of the new publications For those many of us wanting to maintain a complete and current set of books for some subject area, Softcopy Librarian provides a nice approach. But SL itself does not contain the hard part. Rather, it depends on the continued maintenance of IBM's indexes; something IBM is showing little sign of doing. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OSA-ICC in _3215_ mode? Anybody done this?
On 16 September 2013 10:54, John McKown john.archie.mck...@gmail.com wrote: I was looking a the PDFs for z/OS 2.1 and saw: SA23-2247-00 OSA-ICC 3215 Support2.33http://publibz.boulder.ibm.com/epubs/pdf/ioa2sp00.pdf And, being the retro idiot that I am, thought it might be interesting. I know that OSA-ICC can basically present a local non-SNA 3270 controller to z/OS for use by consoles, et al. I think of it as a built-in TN3270 server. Apparently this 3215 mode is something new (to me) that came in around the 1.13 time frame. Does anybody else find this fascinating to think about? Why? Because I can envision having this as a NIP console and run an IPL via a telnet line mode session. Of course it would be more likely to work if z/OS still supported 3215s... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 16 September 2013 12:45, Kevin Minerley k60ek...@us.ibm.com wrote: ) As pointed out, Softcopy Library (SCL) can handle PDFS 2) As for indexing all the base zOS elements, many of the zVSE, and zVM will have indexed PDFs and an associated extended (XKS) shelf. We have instituted a request to other non-base products to consider PDF indexing; but that is a product-by-product (rather then platform) decision. If you're referring to my comment on indexes, this isn't what I meant. I simply meant the .des files that contain pointers to the actual books, whether in .boo or .pdf format, and the metadata necessary to decide if a book is current or has been superceded. It looks as though IBM is not maintaining those files, perhaps because Softcopy Librarian has gone away along with Softcopy Reader, even though SL supports the IBM-preferred PDF format quite nicely. Actually, it's now easier to dowload just a product at a time as the XKS shelves are parts of pkits that all have order numbers. Easier than what? It was much the easier to let SL do the work... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NSA foils much internet encryption
On 16 September 2013 16:04, Anne Lynn Wheeler l...@garlic.com wrote: re: http://www.garlic.com/~lynn/2013l.html#55 NSA foils much internet encryption other trivia ... ECC original invented Miller at IBM Yorktown http://en.wikipedia.org/wiki/Victor_S._Miller followed by Koblitz at UofW http://en.wikipedia.org/wiki/Neal_Koblitz Miller had been in the Yorktown 801 group http://en.wikipedia.org/wiki/IBM_801 Miller is also co-inventor of one the two variations of compression algorithm called LZW. Strangely, if perhaps not unusually, two groups separately invented and separately received patents on the algorithm, and in each case the third initial is W, but in one case Welch and in the other Wegman (the IBM one). IBM's LZW is implemented by terse (AMATERSE and friends), while the other is the base for UNIX compress and the GIF file format. While they are not immediately interoperable, they are essentially the same thing. The Wikipedi article is perhaps a little confusing/confused on this. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 17 September 2013 07:13, Kevin Minerley k60ek...@us.ibm.com wrote: If you're referring to my comment on indexes, this isn't what I meant. I simply meant the .des files that contain pointers to the actual books, whether in .boo or .pdf format, and the metadata necessary to decide if a book is current or has been superceded. It looks as though IBM is not maintaining those files, perhaps because Softcopy Librarian has gone away along with Softcopy Reader, even though SL supports the IBM-preferred PDF format quite nicely. All the electronic-only deliverables SHOULD have the .des file (it is usually in the root). It still works with Softcopy Librarian (SCL). I usually test by installing the electronic-only then starting SCL to see if updates occur (and usually they do as more products are NOT on the main platform schedule then are on the platform schedule). I don't know what that means ( main platform schedule vs platform schedule). Easier than what? It was much the easier to let SL do the work... Before with physical-only media, it was all or nothing. Now you can skip getting the entire collection, go to the Publications Center and only download the products of interest (use the XKS shelf name to get the related docs). But we are surely not contrasting with physical media. I haven't loaded anything from a CD for years. For a long time I've opened Softcopy Librarian, gone to the only Internet source I know of, SL presents me with a list of Product categories: like z/OS V1.13 and Software Products Collection, I choose one, and SL tells me what's neen updated compared to what I have already loaded. Works great. Of course, you can still use SCL to update either the entire electronic collection or individual shelves. Well I could if the .des files were kept up to date, but evidently that's not happening. Which is exactly where we came in 29 posts ago. If the .des files were up to date - in this particular case so that the z/OS V1.13 file contained COBOL V5R1 as well as older COBOLs - Charles would have had no cause to complain. There is surely no reason to tie the .des file content to some now obsolete CD collections. This would be trivial for IBM to fix, but somehow I have the feeling it's not going to happen because it doesn't match someone's idea of how customers should use publications. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Looking for COBOL V5R1 Softcopy Librarian docs
On 17 September 2013 12:03, Kevin Minerley k60ek...@us.ibm.com wrote: Well I could if the .des files were kept up to date, but evidently that's not happening. Which is exactly where we came in 29 posts ago. If the .des files were up to date - in this particular case so that the z/OS V1.13 file contained COBOL V5R1 as well as older COBOLs - Charles would have had no cause to complain. There is surely no reason to tie the .des file content to some now obsolete CD collections. The collection level .des file gets updated every time the deliverable gets produced and put in (usually) the root directory of the collection. At least at this level, IBM is keeping the collection-level .des file current. If you never intend, to download another collection kit, I am not certain that you will get a new suite of .des files. You might consider downloading at least new versions as they usually involve a complete change of order-number/material ID. That should work even against individual products. I have seen it successfully update r13 docs that did not make the initial electronic-deliverable drop. Have you tried using one of the newer .des files? I would if I knew where to get one. Softcopy Librarian offers only choices based on the /epubs/df/ebrscrt.des file, and that has the problems I mentioned above: The comments for the files it points to don't seem to be up to date (e.g. the z/OS 1.13 collection is dated Sep 2012, even though the update date on the directory is Sept 2013), so it's hard to know what's a new file and what isn't. And then the actual collection .des files don't seem to have the new material in them, e.g. COBOL V5R1. Or rather, there exists no file *that is pointed to by a top-level .des file* that contains a list of the COBOL V5R1 pubs. Since IBM has disabled the ability to look at the directory, there is no way I know of to find these things other than by discovering an external reference of some kind, which can't be automated. Can you point me at one of these newer files so I'm sure we're talking about the same thing? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FBA Services (Was: PDS/E, Shared Dasd, and COBOL V5)
On 16 September 2013 19:48, John McKown john.archie.mck...@gmail.com wrote: HFS UNIX filesystems are supported in the OMVS address space itself. zFS filesystems are supported in a colony address space called ZFS. In passing, there is no strong connection between running a filesystem in the UNIX kernel address space or in a colony address space. Most file systems can run in the kernel, and all can run in a colony, unchanged (as the book says). Only those that use a particular colony thread service cannot run in the kernel. There are pros and cons to each environment. Why not support another filesystem type, allocated on the unit record FBA device, in another colony address space? Perhaps even a z/Linux formatted filesystem such as ext4 or btrfs. In this case the single user only allocation is a moot point since all filesystem I/O would be done by the colony address space. Nothing technical stops you from writing one. You can certainly do it in C or assembler, and who knows - maybe in some other languages that don't have too much run-time baggage. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
On 17 September 2013 15:01, Mark Zelden m...@mzelden.com wrote: Does anyone know if there has ever been a requirement to support MOVE as in COPY + DELETE in IEBCOPY like ISPF move does? A newbie asked me about this today. It would be nice I suppose. Instead I pointed him to PDS86, IDCAMS (yuck) or IEHPROGM (double yuck) as a way to delete the members after the copy. IEHMOVE. Heh... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: CVTLSO, SMF, and RMF (was: Where environment variables ...)
On 17 September 2013 17:32, Charles Mills charl...@mcn.org wrote: Is my first sentence correct if I change it to The z/OS system clock is (if your shop follows best practices) set to Universal Coordinated Time (UTC, similar to Greenwich Mean Time or GMT).? I think it's Coordinated Universal Time. Wikipedia claims that UTC is a compromise between English and French acronyms, and also suggests assimilation to the pattern of abbreviations for coordinated time (UT0, UT1, etc.) Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IEBCOPY - MOVE
On 17 September 2013 16:41, Mark Zelden m...@mzelden.com wrote: On Tue, 17 Sep 2013 16:24:10 -0400, Tony Harminc t...@harminc.net wrote: IEHMOVE. Heh... Does the HEH mean you are joking or IEHMOVE is a joke? I kind of thought the one Heh... would do for both. No, it can't be used for this function. Even the functions it does work for For some value of work. (moving a PDS plus merge) don't work with SMS controlled DASD. That wasn't a requirement you mentioned. Regardless, the whole notion of move invites problems. And IEHMOVE in particular has had a long history of deleting source datasets that it thought or claimed it had first successfully copied. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Does z/OS 2.1 support COBOL 4.2?
On 18 September 2013 11:39, John P Kalinich jkali...@csc.com wrote: This web link has end of service dates for IBM products. http://www-01.ibm.com/software/support/lifecycle/index_e.html Where clicking on the z/OS 1.13 line gives me a nice friendly IBM message: Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request. Please contact the server administrator, [no address given] and inform them of the time the error occurred, and anything you might have done that may have caused the error. More information about this error may be available in the server error log. I particularly like the blame the victim and administratorless system attitudes... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PDS/E, Shared Dasd, and COBOL V5
On 20 September 2013 09:28, Farley, Peter x23353 peter.far...@broadridge.com wrote: Tim, I have to disagree in part with the statement you made below that ... it couldn't be avoided. It most certainly *could* have been avoided. It may have been a ... reasonable, responsible technical choice from IBM's more-than-occasionally myopic point of view, but not necessarily the best choice, either technically or politically. A better choice, IMHO, would have been to use the XL C/C++ back end which supports not only load-module output but also supports architectures back to before the G1 series (the XL C/C++ documentation for ARCH(0) says: Produces code that is executable on all models.). All the benefits of newer-architecture instructions and advanced optimization algorithms would have been made available without *requiring* program-object output and thus PDSE storage. At risk of going off on a bit of a tangent, I've been wondering quite a bit about this choice. And more fundamentally, why there are two current code generator back-ends in IBM with obviously overlapping function. And I think they even come from the same lab in Toronto. I had imagined the key feature of a Java back end to be Just In Time compiling, because in general JVM classes cannot be pre compiled, but need to be translated on the fly, often in small chunks yet with good performance, so that a tiny function doesn't have a big startup cost when called, yet its performance can improve with experience. A COBOL back-end - like one for C or PL/I or FORTRAN or any traditional language - would presumably want to generate the best possible code with the luxuries of lots of available compile-time resources, cross-procedure/module optimization, and so on. Now these goals are obviously not incompatible, indeed they overlap hugely, but I wonder if this is just the latest in a decades-long series of IBM internal competitions where both products are allowed to get out the door before one is eventually killed off. And if the Java one is winning the new business, as it were, is the C one going to be kicked out of C and PL/I in due time? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: UNICODE to EBCDIC
On 23 September 2013 20:18, Paul Gilmartin paulgboul...@aim.com wrote: On Mon, 23 Sep 2013 16:56:46 -0700, Charles Mills wrote: There is actually a Unicode EBCDIC (UTF-EBCDIC) but it's pretty obscure. Not as obscure as it deserves to be. Never miss a chance on this one, do you Gil... As you know, I think UTF-EBCDIC was a great idea, and can't understand how it failed to catch on. Maybe there's just not much call for invoking legacy interfaces on the IBM zArch OSs with new data. Or perhaps UNIX programmers are lazier. Or something... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Pissing contest(s)
On 23 September 2013 21:56, John Gilmore jwgli...@gmail.com wrote: I suspect that the phrase and its variants have multiple etymologies, with much semantic cross contamination among them. Indeed. I had imagined that any actual such contest would be engaged in only by small boys, and that the phrase is used to point out the puerile attitude of those supposedly engaged in it. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Optimization, CPU time, and related issues
On 20 February 2014 21:40, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: on 02/19/2014 at 02:43 PM, Tony Harminc t...@harminc.net said: I didn't suggest, let alone say, anything counter to this. Then who wrote Indeed this is the way conditional execution and branching works (and has always worked) in channel programs.? It was surely clear from the context that I was speaking of the S/360 and its descendants. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
On 21 February 2014 11:37, Chase, John jch...@ussco.com wrote: Browsing the dumped storage around the program's load address (x'7000') I see: Event 1 CSECT DBR915B0 GPR 15 (Address 7000) 700080ECD00C*..}.* WTF??? In the program source the first instruction is: USING *,R15 DBR915B0 CSECT STM R14,R12,12(R13) But STM's opcode is x'90', not x'80'. X'80' is SSM (Set System Mask), which is a(nother) privileged instruction. And one that the program could not have survived executing; it is not only privileged, but in most cases you will encounter on z/OS will produce a special operation exception if your program *is* in supervisor state. So, assuming this is the entry point of the program, that is, the first instruction to be executed and not only the first one physically in the module, it seems very likely that this instruction was modified after some part of the program had already executed. So, it appears that for some as-yet undetermined reason, this program (to the exclusion of all others) IFF loaded from a PDSE has its first instruction changed somehow from STM to SSM. Can you say That's absurd!? That's absurd!. But I can also say as above that it's unlikely it was loaded that way. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C2 in DB2 application program (was Stored Procedure) IFF run from a PDSE
On 21 February 2014 15:28, Chase, John jch...@ussco.com wrote: It appears from our tentative diagnosis that the MVCK instruction was not in executable code, but rather was just data in the PARM passed to the program at invocation. Thus the questions about where the system places PARM data before transferring control to the user program. It surely doesn't place it on top of your program code... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Curious observation: lack of a simple optimization in a C program
On 24 February 2014 10:44, Anne Lynn Wheeler l...@garlic.com wrote: two people from the Los Gatos VLSI lab originally did mainframe pascal for VLSI chip tools ... this goes on eventually to become the vs/pascal product. Amoung other things it was used to implement the original mainframe TCP/IP support. It originally had some performance issues ... getting around 44kbytes/sec throughput using 3090 processor. However, I did the RFC1044 changes and in some tuning tests at Cray Research got sustained channel media throughput between Cray and 4341 using only modest amount of the 4341 processor (possibly 500 times improvement in bytes moved per instruction executed). past posts mentioning doing rfc 1044 support You've mentioned this a number of times, but I don't think you've explained what you did to the Pascal code to get a 500x improvement. Was the original code exceptionally bad, was your new code exceptionally brilliant, did you take advantage of some knowledge of the VS Pascal code generator or were your changes applicable to code in any language...? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On 2 March 2014 18:30, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: [1] Does IBM have a z/OS code page for ISO 8859-15 yet? IBM has produced only two code pages for Latin-9; one ASCIIish (923) and one EBCDIC (924). Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OCOPY fails to convert text
On 3 March 2014 20:54, Farley, Peter x23353 peter.far...@broadridge.com wrote: GIYF. I refer you to these Wikipedia references, the first of which makes it quite clear that iso-8859-1 is definitely NOT Windows, though it does call it ASCII-based; and the second of which is a nice reference for IBM-1047, from which you can see that there is a reasonable chance to convert between the two encodings, though not completely transparently, whatever IBM chooses to call the iso-8859-1 encoding. More than a reasonable chance; since IBM-1047 and ISO-8859-1 encode *exactly* the same set of displayable and control characters (what IBM calls Character Set (CS) 697, and ISO calls (duh) Latin 1)), converting without loss is trivial. Windows, when it uses them at all, uses code pages that contain displayable characters in places where 1047 et al have control characters, so it is not in general possible to convert from e.g. Western Windows 1252 to IBM-1047 without loss. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 9 March 2014 09:01, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: Much earlier, someone decided that the power unit for the 650 was of a convenient height for drying socks. A Selenium rectifier blew out. Not a pleasant smell (the rectifier; no comment on the socks), as anyone who's been near a cooked one will know. There are easily found refs to the increasing horribleness and persistence of the smell of certain organic sulphur, selenium, and tellurium compounds (and the near impossibility of ever knowing what compounds of the next element down the column in the periodic table - polonium - might smell like. Of course working up the column instead, DHMO doesn't small bad at all. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [OT ] Mainframe memories
On 10 March 2014 10:57, Anne Lynn Wheeler l...@garlic.com wrote: I would tend to use the distinction that for the psect, a private copy was loaded and adjusted for the specific virtual address space location ... separately from (r/o) memory mapping the executable image with no requirement for pre-loading and/or changing ... allowing the same exact (r/o) executable image to concurrently occur simultaneously in different virtual address spaces at different virtual addresses (with just a per virtual address space private copy of the psect having been preloaded and swizzled). The overlay scheme used in HASP II had fixed-sized modules that were read into an available area without relocation. If the space was needed, when the first module got control again it could be loaded at a different address. But the trick was that these tasks were never preempted, so it was permissible to have a register containing an address within the module, as long as it was made relative before (loosely) calling the dispatcher, which might result in relocation. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: all this crap from Umberto Silvestri
On 11 March 2014 13:17, Bonno, Tuco t...@cio.sc.gov wrote: anybody know how to set up Microsoft Outlook to purge/quarantine/shitcan all this stuff we're getting from him ? Maybe someone (or all of us) should call the local IBM office and complain about this. IBM is notoriously bad with these OOO notifications. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another reason to hate the time change
On 11 March 2014 08:48, Paul Gilmartin paulgboul...@aim.com wrote: My microwave oven and my clock radio don't support 24-hour. Microwave ovens are an odd case, because some support 24-hour time, but most don't. But more interestingly many of them support a curious mixed-base notation. So I can set my coffee to heat for 1:30 minutes or 90 seconds. In my case the display counts down following what I entered, but I saw one once that instantly converted an entered number of seconds exceeding 59 to the h:m:s base when I hit start. My bicycle computer is peculiar: it offers either km/24-hour or mi/12-hour, but not the other two quadrants. It's probably based on UNIX/POSIX, which has the BAD notion of locale. I've been trying to set Eclipse to use ISO 8601 dates and times, and the closest I've got is to set the locale to sv_SE, which of course breaks other things. This is one of those rare cases where Windows gets it not just practically, but conceptually right. Though I notice that in Windows 8 they seem to have removed some date format choices! Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: S0C1 TSO TESTAUTH
On 12 March 2014 11:54, MichealButz michealb...@optonline.net wrote: [blank lines removed for readability] I am setting a breakpoint at offset +0 in my program and getting a S0C1 at location +E The following is my scenario TESTAUTH 'ISP.SISPLPA(ISPF)' CP LOAD 'MYLOAD.LIBRARY(MYMOD)' Q MYMO.MYMOD.+0 AT +0 GO à INTO ispf Then from the ispf command line I do TSO MYMOD And S0C1 Are you sure that +0 is the entry point of MYMOD? Why not look at the instructions starting at MYMOD.MYMOD.+0 -- surely that will give you some clue as to what happened. While you're there you could look at the registers... Oh yes, and maybe the PSW. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: building text messages with substitutions
On 13 March 2014 11:08, Donald Russell russell@gmail.com wrote: I've been using WTO ROUTCDE=11 to display various message in the job log of assembler language batch applications that's great/easy for fixed text messages. VM/CMS has the APPLMSG macro which makes it ridiculously simple to build in storage, or display messages with various types of substitutions... I would like to display a message like: Records read: Items found: Hit rate: zzz% Where the value for x,y and z come from registers or fields. Of course I can do it myself with CVD/EDMK etc, but this seems like such a common sort of thing, I hoping there's a macro to do that stuff for me. Even if the macro builds the message in storage, then I can use WTO ROUTCDE=11 pointing to the text result. How about the C library sprintf function? If you use the Metal C version, it can probably be called from assembler in a non-LE environment. It does require a stack (R13 save area) of around 4KB, iirc. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: building text messages with substitutions
On 13 March 2014 14:01, John McKown john.archie.mck...@gmail.com wrote: Wish I had thought of using the Metal C version of sprintf(). I actually ended up figuring out how to write a number of z/OS UNIX commands using LE enabled assembler so that I could use things such as sprintf() or snprintf(). Well Metal C hasn't been around for all that long. There is also System Programming C, which has a different set of requirements for its subset C library that are still easier to meet than the full LE ones. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: building text messages with substitutions
On 13 March 2014 14:53, Donald Russell russell@gmail.com wrote: Holly Smokes! Metal C looks perfect THANKS! :-) I just need sprintf features Please keep us posted with your results. I haven't actually tried it, but I've thought about it a few times - enough to look at the calling and environment conventions. They look pretty easy to meet, but stack space requirements are large in comparison to typical assembler programs. If you're calling only sprintf you could presumably reuse or otherwise share the stack, i.e. what you pass to the function wouldn't have to be an actual stack that your program linkage conventions use. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Testing out TSO Authorized commands
On 13 March 2014 15:39, Micheal Butz michealb...@optonline.net wrote: I have authorized TSO command actually a program that issues a modeset to get into supervisor state When I run this program under TESTAUTH to debug it And it is in AUTHCMD/AUTHPGM In IKJTSOXX I get a s0c1at the begining of the program However running it standalone I need the table entires to do a modeset Would anyone have an explanation No. Set a SLIP and capture details of the 0C1. TESTAUTH may not be accurately reporting where it happened, and the state of its SVC 97 breakpoint overlays. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: building text messages with substitutions
On 14 March 2014 01:51, Donald Russell russell@gmail.com wrote: I've been looking for doc on how to do this It seems I need to call __cinit to set up a C environment, then I can call sprintf and finally __cterm to terminate the C environment I'm not sure, but the way I read it sprintf() doesn't need that environment. The books says, in the section describing __cinit(), This environment is used when calling Metal C functions that require an environment, such as those related to storage management (malloc(), free(), and so on). The description of sprintf() does not mention an environment, but in contrast that for snprintf() explicitly says Use of snprintf() requires that an environment has been set up by using the __cinit() function. When the function is called, GPR 12 must contain the environment token created by the __cinit() call. So I would just try it with R13 pointing to a standard save area with 47KB (from Table 14 in the book) beyond the 72-byte SA, and see what happens. Set up the SA Perhaps set R12 to zero or to a recognizably bad address to help catch any reference to it. And you probably have to set the NAB to point to the (duh) next available byte in the SA. Best bet would be to compile a Metal C hello world that calls sprintf and see what the setup and call looks like. There also seems to be a choice of using the library routines from LPA, or binding them with your program. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: curious: volsers 6 non-blank chars non-numeric tape
On 14 March 2014 13:49, John McKown john.archie.mck...@gmail.com wrote: 1) Has anybody ever had a VOLSER which was not exactly 6 non-blank characters for a regularly used volume? Especially any trailing blanks? Decades ago the university I worked at had a standard of N and F for Native and Foreign tapes, respectively. I don't know why they were all five characters, but surmise that there were occasional historic reasons to have slots labeled with a suffix. Regardless, they are perfectly legal volsers. For some reason many people have insisted to me over the years that not only must tape volsers be all numeric, but that leading zeros will be inferred if not supplied. Both these claims are untrue. The rules for tape volsers are not different from those for disks. 2) Has any commercial shop ever used non-numeric tape volume serials for normal in-house tapes? If so, why? Yes - see above. Well, perhaps a university is not commercial in the sense you mean, but we were very much a production shop, and not a nest of developers. I ask because, at least historically, CA-1's support of non-number tape serials was difficult (needed some sort of mapping exit as I recall). Heh... We were a very early installation of what is now CA's ASM2 archival system. In those days, it used IEHMOVE (cringe) to offload data to tape, and the generated control statements included a full six bytes of tape volser, which predictably IEHMOVE didn't like. Well, not so much didn't like, but treated the characters after the trailing blank as a comment, with at times disastrous results. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Difference between MVS and z / OS systems
On 17 March 2014 13:51, John Eells ee...@us.ibm.com wrote: MVS was the prior name of what has become z/OS. What was started out as MVS in 1974 was renamed to: [...] Although the name MVS was around in 1974, IBM chose, for the usual marketing reasons of the day, to sell it as OS/VS2 Release 2, presumably to emphasize continuity with the very different OS/VS2 Release 1 (aka SVS), which was essentially MVT virtualized into a single 16 MB address space. It took a long time for the names MVS (and SVS, for that matter) to appear in official publications; many if not most pubs still had titles with OS/VS2 Release 3.7 and no mention of MVS into the late 1970s. There is some evidence that the product was going to be called MVM (Multiple Virtual Memories) at one time. For quite some time after release of OS/VS2 Release 2, the IEHDASDR program printer a heading line containing MVM DASDR. There is a different sense of MVS, and that is, as John Chase said 'MVS is the kernel; z/OS is the whole package'. This, though, came about only when MVS/XA appeared with the non-optional Data Facility Product (DFP) in addition to the core operating system. Two labs, east coast, west coast, etc... These were re-integrated only with the OS/390 bundling. I doubt any one present -- even Lynn Wheeler -- knows all the politics behind all these changes. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Difference between MVS and z / OS systems
On 18 March 2014 12:00, Paul Gilmartin paulgboul...@aim.com wrote: How did the 67 deal with legacy code's use of the sign bit to terminate parameter lists? I doubt that much legacy code ran on such a machine in 32-bit mode. There would surely be other reasons to run such code only in 24-bit mode - not least the common use of the entire high byte of an address to hold flags and such. Did it also have a 31-bit mode? But I suppose most such code was written for 24-bit addressing. It did not have 31-bit mode. PSW bit 4 was the 24/32 switch when in Extended PSW mode, which in turn was controlled by a Control Register bit. It's interesting that USASCII mode (bit 12, which became the BC/EC bit in virtual storage S/370s) was supported in both PSW modes. But I never actually saw one, let alone worked on it, so I'm just interpreting the Functional Characteristics. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: APAR OA30338 for PDSE Users
On 20 March 2014 10:48, Jim McAlpine jim.mcalp...@gmail.com wrote: Thanks Tom, that was the cause of the problem. I logged off TSO and back on again and was able to delete the offending dataset. Sorry for sending everyone off on a wild goose chase. Well you didn't exactly have ideal information to work with. I mean, seriously, IEC614I SCRATCH FAILED - RC 008, DIAGNOSTIC INFORMATION IS (043D57D3), SYSACCT,DB2B04,E54I.OLAS.PDEFLIB is hardly the most friendly way of saying dataset is in use by job the way other programs generally do under similar circumstances. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: NJE Clarifications
On 21 March 2014 11:18, Jake anderson justmainfra...@gmail.com wrote: For an NJE to work we must have to two different nodes. Is there a way for NJE to work within a single Node(Monoplex) just to communicate to another product(As a socket-Running in same Node) ? For many years (decades, actually) there have been other products (IBM and non-IBM) that talk the NJE protocols. Most notably, IBM's RSCS on VM uses an overlapping subset of the same protocol, and is interoperable. There have been NJE implementations for UNIX and other operating systems over the years, long predating NJE over TCP/IP. One popular product in the 1980s was JNET, from Joiner Associates, which ran on the DEC VAX. Is there a case study for the NJE to work on a Monoplex environment ? I tried looking at the share site or JES2 tunning guide But I do not see anything about NJE on Monoplex. I don't know what you mean by a case study. Do you have a problem to solve that you think NJE can somehow address? Are you just trying to understand how things work? Or making up a checklist or the like? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Reflexivity (was: NJE Clarifications)
On 24 March 2014 08:11, Paul Gilmartin paulgboul...@aim.com wrote: On Sun, 23 Mar 2014 20:12:49 -0400, Shmuel Metz (Seymour J.) wrote: I''m not asking a question; I'm pointing out a false analogy. TCP/IP, in contrast, is blessedly tolerant. makes no sense. ... I'm asking in what sense TCP/IP is more tolerant than SNA. It's certainly not in the ability to run multiple applications on the same host, since SNA does that as well as TCP/IP does. I can use FTP (a TCP/IP protocol) to submit jobs to localhost. I do not need multiple TCP/IP stacks to do this; only a conventional TCP/IP configuration. Generally, TCP/IP-based protocols such as FTP, HTTP, SSH, ... can communicate with localhost with no special configuration. The discussion here indicates that to use NJE to submit jobs or otherwise communicate with the local host requires some unusual configuration such as multiple instances of JES or multiple instances of NJE. So, I perceive TCP/IP as more tolerant; it has no bias against the local host. Nonetheless the analogy fails. NJE is a protocol (and loosely, an implementation of the protocol) that uses an underlying transport layer of SNA or TCP (or originally and perhaps long gone, BSC, which predates most notions of layering along the lines of TCP/IP, OSI, and so on). There is no reason to expect all users of a transport layer to implement the same functionality. In the cases of FTP and Telnet, there is notionally always a client and a server, and certainly a client on one system can connect to and meaningfully use the services of a server on the same system. In the case of NJE, each endpoint is a node. (Poor choice of word, perhaps, but we're not here talking of graph theory or CS trees, and one can even argue there are leaves in NJE, though they're not called that.) Each node both provides services and acts as a client to other nodes, and there are well defined rules for the routing and transmission of units of work (jobs, sysout, etc.) from one node to another, possibly via intermediate nodes. It is not a deficiency or lack of generality that a node is not willing to talk to itself as though it were another node, any more than is the refusal of a web server to talk to other web servers, or Telnet clients to other Telnet clients. To allow this -- to some unclear end -- routing rules would have to be changed to avoid loops, and the system as a whole would surely be allowed to optimize out the unnecessary sending of a UW from a node to itself, as it does today when you use e.g. /*ROUTE XEQ localnode. There's another view of all this. Historically, although as Lynn Wheeler has pointed out innumerable times the JES2 implementation of NJE had a fuzzy mix of routing and transmission protocols with SPOOL related matters, one can think of NJE as a routing scheme using BSC as the link layer, with the routable units being spooled units of work. In the early days of NJE, Vnet, Bitnet, and smaller intra-company networks, it was entirely normal for units of work to be routed through multiple nodes on the way to their destination. In this model, the NJE nodes were analogous to today's IP routers, with the services (printing, job execution, etc.) provided at a leaf, implemented on a node and unfortunately to some extent integrated into the same code that provided the routing. Indeed the larger networks (Vnet, Bitnet) had a number of routing-only nodes and what we would today calle firewalls or gateways that provided no local services at all. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: old RJE 360 workstation mod - reflexivity
On 24 March 2014 12:03, Bill Godfrey yak36...@yahoo.com wrote: The current thread about reflexivity reminds me of an old program we tested in the mid-70's, before NJE, that was called the Iowa Workstation. It was a modification from the University of Iowa of the HRTPB360 program that came with JES2, that allowed it to run as a task on MVS instead of on an RJE station, so the MVS system could appear as an RJE station to another system, or to itself. I'm not sure if we ever used it to connect to a separate system, certainly not on a regular basis, but we must have tested it by connecting it to the same system it was running on, presumably using bisync. Maybe someone here will correct me, saying No, that would not be possible with bisync. It was certainly possible; I too did it for testing on VS1 in the mid 1970s, though with my own mods. HRTPB360, btw, is shipped to this day with z/OS as SYS1.MODGEN(HRTPB360). Hmmm... quite possibly this is the only piece of z/OS source code that is still shipped and explicitly marked COPYRIGHT = NONE. If only the IBM lawyers knew... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C vs. HLASM - for C callable subroutine?
On 25 March 2014 16:16, Paul Gilmartin paulgboul...@aim.com wrote: Wouldn't it be nice if all the header files were trilingual? Assembler/PLS/Metal C? It'll take a while. Ugh, please. :-( There's nothing wrong with Metal C that a complete redesign wouldn't fix. But in any case, what would you do to allow PL/X and C to pick out their own code? The assembler vs PL/X or C comment format makes it easy, but both PL/X and C have /* comments */ . Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C vs. HLASM - for C callable subroutine?
On 25 March 2014 16:56, Paul Gilmartin paulgboul...@aim.com wrote: But in any case, what would you do to allow PL/X and C to pick out their own code? The assembler vs PL/X or C comment format makes it easy, but both PL/X and C have /* comments */ . #if ? But how will both PL/X and assembler not see it? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C vs. HLASM - for C callable subroutine?
On 25 March 2014 18:11, Paul Gilmartin paulgboul...@aim.com wrote: #if ? But how will both PL/X and assembler not see it? That's their problem. Perhaps AGO for assembler. And hasn't PL/X something similar? Well you can't reasonably ask for trilingual macros and then shrug your shoulders when asked for how it might work. Surely each language can't be expected to add something to its syntax to bypass all the others. Right now the scheme works because lines starting with * are assembler comments, and the PL/X compiler option MARGINS(2,n) is used so it doesn't see the comment '*'s. IBM C has a MARGINS option too, so that would work, but how are PL/X and C to each find only their own stuff? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Metal C generating junk for long input lines?
Speaking of Metal C, I'm seeing a strange thing just recently. My C input
is a VB 255 PDSE member, and the output is an FB 80 PDSE member. Whenever
an input line exceeds 80 characters, the output assembler source has a
bogus line with unprintable characters where the wrapped part of the
original C line should be.
For example, with this input:
int main(int argc, char*
argv[])
{
int rc; // this line has a very (though not unreasonably) long comment
going beyond column 80
return
rc;
}
The relevant section of output has:
* {
03
*
04
* int rc; // this line has a very (though not unreasonably) long com
05
V# Ê rgW2
05
*
06
* return rc;
07
L 15,@5rc
07
* }
08
The junk on the second line 5 varies from one time to the next, but is the
same in a given compile, and always has the V#. In this case the whole
string is X'E57B0419722A109987E6F2'. It's not only comments; a long line of
actual C does it too. (And yes, I know I didn't set rc. That doesn't affect
the problem.)
This is Metal C '5650ZOS V2.1 z/OS XL C'. I don't remember seeing anything
like this earlier, and I see no APAR hits. Am I about to have a duh! moment?
Could someone else try this snippet?
Tony H.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Metal C vs. HLASM - for C callable subroutine?
On 25 March 2014 19:03, Paul Gilmartin paulgboul...@aim.com wrote: Well you can't reasonably ask for trilingual macros and then shrug your shoulders when asked for how it might work. Actually, I can. That's an implementation technique. Suppose a Requirement for trilingual macros were to be submitted to IBM. It's my understanding that when considering Requirements, IBM discourages the users' specifying implementation techniques, desiring only objectives instead. Sigh. By the same token asking for trilingual macros is an implementation technique. What is the business problem you want IBM to address? Perhaps shipping mappings for all three languages, with identical names and such? Then maybe IBM can decide if a trilingual approach is the best fit. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocating file in Rex exec
On 25 March 2014 21:50, Micheal Butz michealb...@optonline.net wrote:
Alloc fi(myddnam) da('my.pds.name(member)') shr
I get an error routine not found
You are calling a REXX function named my.pds.name(member) which
presumably is not what you intended. Why do you have those inner
double quotes?
Tony H.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 26 March 2014 12:20, Charles Mills charl...@mcn.org wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. It depends to a great extent on the nature of the product. If it contains/provides its own database of some sort, then there's no need for a magic hidden file; it can just store the key info and install date in some obscure corner of the database. Likewise, if the program is APF authorized by its nature, there are plenty of legitimate places it can store the info - most obviously in the security system, and as dataset or file metadata. But it all depends on what you're trying to accomplish. I imagine it's a matter of convenience for you and prospective customers. But if you are seriously worried about unauthorized use (say, beyond the time of a trial), then there are all sorts of other considerations that have been discussed at some length here in the past. These days even the act of hiding key and data info somewhere may provide you (in the US, at least) with a DMCA stick to threaten your customers with should they attempt to figure out where and how you've hidden things. But I'm sure you wouldn't want to even think of that. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Installing z/os in new mainframe from scratch
On 28 March 2014 02:28, Mohamed Juma mmj...@yahoo.com wrote: What is the recommended way to install z/os from scratch to a new data center, includes new hardware z machine, DASD, tape system. If you are in this unusual position, IBM will surely be already knocking at your door to help you do all this. For a very reasonable fee, of course. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Compiler error in z/OS C compiler
On 28 March 2014 09:47, Bernd Oppolzer bernd.oppol...@t-online.de wrote: I just realized that NULL returning 0xFF00 was designed when we still had 24 bit addressing, so there must have been other reasons for this design decision. I remember heated discussions on this matter at my university computer centre in the early 1970s, long before 31-bit addressing on S/370. At the time it was very common for assembler code to use the high byte of a fullword address to hold flags of various kinds, and the notion of indicating a NULL pointer out of band is attractive. Some people even then had a longer view, and understood well that 24-bit addressing would not do forever, and that something would have to be done. One can see the evolution of this thinking in (IBM and others') assembler coding style as flags were moved out of high address bytes. Another thing to consider is that pointers in C and PL/I are, in their different ways, both opaque objects with only certain defined external properties, and various implementation details. For example, in the PL/I Checkout Compiler, pointers were, iirc, 128-bits, and carried various information far beyond the address that allowed the production of useful run-time debugging messages. In C, pointers are very clearly not addresses at all. Look at the semantics of adding an integer to a pointer (which is defined in the language, and is not just an implementation detail): if your pointer is to an array of, say, ints, if you add 1 to it it will point to the next int in the array, not to the next byte within the current int. PL/I has its Unspec Built In Function, and C has its cast, but both when applied to pointers have implementation defined results. Perhaps your solution lies not in the C language, but in the compiler-defined external linkage conventions, some of which can be chosen by various pragmas. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: RES: Messages Prefix
On 28 March 2014 14:00, Elardus Engelbrecht elardus.engelbre...@sita.co.za wrote: Look in Relating component ID to component name, module prefix, and product in book MVS Diagnosis: Reference. This one should help you in a way for IBM software. I believe someone said on IBM-MAIN that IBM reserves the first letter of the prefix for themself and other vendors should rather use other unreserved letter. In theory IBM owns all prefixes starting with A to I, and also Q, and the rest are for ISVs,customers, etc. IBM operates a registration service for these prefixes, but many ISVs, and on occasion IBM itself, do not follow the rules. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
IBM Explorer for z/OS - installation problems?
I thought I'd try it, but on my Windows 7 the installer just quietly exits. Of course I can provide more details if I know what's important, but have some of you installed it and had it Just Work? Any pointers? I downloaded it from http://www-01.ibm.com/software/htp/cics/ibmexplforzos and tried Scenario 1 - Install z/OS Explorer and Installation Manager. Thanks... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
