Re: Exclusive ENQ on dataset owned (SHR) by Started Task?
To safely process a PDS member, use the SPFEDIT ENQ and RESERVE. Doc at: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/APPENDIX1.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ispzpc90/APPENDIX1.1.3 This is only safe if all programs follow the same rules. In SAS/C, we supply an open parm (share=ispf) to accomplish this. Peter Relson wrote: It is not necessary have a data set ENQ'd exclusive to delete a member, as evidenced by such functions as ISPF 3.1 There is a protocol for deleting members that applications such as ISPF use. I'm not positive just what that protocol is, but it does not involve getting the data set ENQ exclusive. On the other hand, FWIW, anyone who compresses using IEBCOPY with the data set allocated DISP=SHR (not an exclusive ENQ) as opposed to DISP=OLD is asking for trouble (and in many cases will indeed find trouble). Peter Relson z/OS Core Technology Design -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How to leave ISPF
In article 9817663136320041.wa.paulgboulderaim@bama.ua.edu you wrote: On Fri, 25 May 2012 15:54:05 +0200, R.S. wrote: When one leaves ISPF usually there is a panel Specify Disposition of Log Data Set. Usually the answer is 2 - delete. Q: how is it possible to exit ISPF by choosing some option (X - Exit) and NOT see the panel? I saw it many moons ago. BTW: I don't ask how to logoff TSO immediately after leaving ISPF. This is another issue. If I'm in SDSF, I type C in front of my user ID. I miss the VM CP LOGOFF command. Blink of an eye. -- gil If you don't mind just abending yourself, you could always hit SYSREQ and type in LOGOFF. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: LE C calling HLASM
#pragma linkage(identifier, OS) In article b870629719727b4ba82a6c06a31c291232410ae...@hqmailsvr01.voltage.com you wrote: When writing an LC C program that calls an HLASM function, the last element of the parameter list does not have the high-order bit set. Is there an option to force it to do so? We can't seem to find one?! -- ...phsiii Phil Smith III p...@voltage.commailto:p...@voltage.com Voltage Security, Inc. www.voltage.comhttp://www.voltage.com (703) 476-4511 (home office) (703) 568-6662 (cell) -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Backlevel IPCS issue at z/OS 1.13
i Bob Shannon bshan...@rocketsoftware.com wrote: Q1) Any idea why TSOLIB ACTIVATE DDNAME(IPCSLIBS) appears to work at z/OS 1.11 but not at 1.13? No idea. Q2) Am I wasting my time here. Should the latest version of IPCS work with all older dumps? No, what you are trying to do is necessary. IPCS is not backwards compatible. Sure it is. Q3) If the answer to 2) is no then how do other people do this? We copy the IPCS stuff to datasets with a different HLQ. As a vendor we receive dumps from a lot of back level systems so we keep the IPCS datasets forever. You just need the proper SYS1.MIGLIB. Everytime we go to a new release, I make sure I have a copy. If I get a dump from a previous release, I place the older release in my TSO STEPLIB. (Actually, I have DDs allocated with older releases in the concat and just issue TSOLIB ACTIVATE.) Bob Shannon Rocket Software -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Why _TZ put times 7 minutes off?
It probably means that an operator reset the local time at the console. Or someone placed an odd value in your SYS1.PARMLIB(CLOCKxx) In article 07f601ccf8d1$6c093da0$441bb8e0$@mcn.org you wrote: 12062 19:01:40.12 TSU02110 0090 IEE136I LOCAL: TIME=19.01.40 DATE=2012.062 UTC: TIME=00.08.40 DATE=2012.063 Well, by George, I think you've got it. They have UTC set 7 minutes ahead of reality. Does this make sense to anyone? I will inquire of our powers that be. I only wasted about two hours on this thinking it was my bug somehow. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Bob Rutledge Sent: Friday, March 02, 2012 3:55 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Why _TZ put times 7 minutes off? What does the d t command return? -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
Jan MOEYERSONS wrote: On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin paulgboul...@aim.com wrote: Set time zone with tzset(). Call localtime() then strftime(). I am not sure this will work correctly. The gmtime(), localtime() and mktime() always use the daylight savings situation of the current date, not of the date input to these functions. Which is an error, IMHO. Cheers, Jantje. For historic local times, you'll need to add some logic to deal with the changing start and stop of DST. DST started in 1966 and changed in 2007, so if you have a date you want to convert that is in that range, first do (for your particular time zone, this example is for the East Coast...): setenv(TZ,EST5EDT,M3.2.0,M11.1.0); If the year is 2007 or later, be sure to first reset to the current value: setenv(TZ,EST5EDT,M4.1.0,M10.5.0); Not as nice as TZDATA, but not rocket science. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: How convert historic STCK to local time?
Don Poitras wrote: Jan MOEYERSONS wrote: On Tue, 28 Feb 2012 12:17:46 -0600, Paul Gilmartin paulgboul...@aim.com wrote: Set time zone with tzset(). Call localtime() then strftime(). I am not sure this will work correctly. The gmtime(), localtime() and mktime() always use the daylight savings situation of the current date, not of the date input to these functions. Which is an error, IMHO. Cheers, Jantje. For historic local times, you'll need to add some logic to deal with the changing start and stop of DST. DST started in 1966 and changed in 2007, so if you have a date you want to convert that is in that range, first do (for your particular time zone, this example is for the East Coast...): setenv(TZ,EST5EDT,M3.2.0,M11.1.0); If the year is 2007 or later, be sure to first reset to the current value: setenv(TZ,EST5EDT,M4.1.0,M10.5.0); Not as nice as TZDATA, but not rocket science. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 Sorry, had those backwards. The new DST starts in March, ends in November. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: where do you store your tcpip configs
SAS/C will look in lots of spots. http://support.sas.com/documentation/onlinedoc/sasc/doc750/html/lr2/z2netget.htm This is pretty much the same as IBM documented back when we first wrote our resolver functions. It's changed since then. The current list is at: http://publib.boulder.ibm.com/infocenter/zos/v1r13/topic/com.ibm.zos.r13.halz002/resconf.htm#resconf In article caapqkjtt1ra_9lm5whfmqpovu4g4gkskfrdpsribb4gpsb8...@mail.gmail.com you wrote: OMVS.PROD.TCPIP.PARMLIB for all parms. * * *George Rodriguez* On Mon, Feb 27, 2012 at 3:59 PM, Rob Schramm rob.schr...@gmail.com wrote: I am curious, I have seen various versions of where people store PROFILE and other parms for TCPIP. sys1.tcpparms sys1.xxx.tcpparms tcpip.tcpparms and probably a few others... is there any consensus where they are typically stored? Rob Schramm Senior Systems Consultant -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 in CEE3DMP
Then you should open a PMR with IBM. They have two problems to solve: 1. An abend in CEE3DMP 2. Incorrect diagnotic message In article 01f001cce108$66577f60$33067e20$@mcn.org you wrote: It's not blowing up in SignalHandler.C; it is blowing up IN CEE3DMP: I get half of the CEE3DMP output and no I'm all done message. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Don Poitras Sent: Tuesday, January 31, 2012 8:18 PM To: IBM-MAIN@bama.ua.edu Subject: Re: S0C4 in CEE3DMP Tea leaves are good for making tea. :) I would compile SignalHandler.C with the LIST option to see the psuedo assembly output and see from the dump where the abend occured and try to figure out what went wrong. The message you've given wouldn't lead me to think there was a problem in CEEDMP, but rather in the calling code. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: S0C4 in CEE3DMP
Tea leaves are good for making tea. :) I would compile SignalHandler.C with the LIST option to see the psuedo assembly output and see from the dump where the abend occured and try to figure out what went wrong. The message you've given wouldn't lead me to think there was a problem in CEEDMP, but rather in the calling code. In article 00f801cce057$c5539eb0$4ffadc10$@mcn.org you wrote: I am getting a S0C4 (apparently - assuming I am reading the tea leaves correctly) calling CEE3DMP from a C linkage signal handler routine in a C++ program under v1.13. I believe the code used to work under V1.10 but I am not absolutely certain that nothing has been changed. I am using leawi.h for the declaration of CEE3DMP. Here is my calling sequence: _CHAR80 dumpTitle = My dump title here; // do not exceed 60 characters per z/OS V1R10.0 Language Environment Programming Reference _CHAR255 dumpOptions = BLOCKS,REGSTOR(256),FNAME(CZADIAG); _FEEDBACK fc; CEE3DMP(dumpTitle, dumpOptions, fc); Here is the SYSOUT output that leads me to believe the problem is CEE3DMP: CEE3204S The system detected a protection exception (System Completion Code=0C4) From compile unit /u/xx/Source/SignalHandler.C at entry point sigHandler at statement 92 at compile unit offset +016A at entry offset +016A at address 15383292. Statement 92 is the CEE3DMP call above. The whole situation is a little confusing because the error in question that triggered the Signal is also a S0C4. (It is intentional as part of a test; there is no reason to think that storage in general is corrupted.) The CEEDUMP output on DD CZADIAG correctly diagnoses the original S0C4. What should I be looking for? Any clues? Thanks, Charles -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: STEPLIB problems - was: PDSE
In article a90e503c23f97441b05ee302853b0e62616721c...@fspas01ev010.fspa.myntet.se you wrote: The original case by Juergen touches the main shortcoming of IBM's STEPLIB-stance. There are cases when putting steplib(s) in linklist simply do not work! And where the alternative of putting it in the logon procedures is working nearly as bad. I have several times seen those cases luckily (= allowed by management) been solved by dynamic steplib functions from outside IBM. This happens when You must use conflicting software or software versions. One such case was when we were upgrading DB2 and during that period was the different test/development DB2 systems on different release levels. Another case was when we had different software (in the TSO development environments) that relied on the same set of SAS/C modules for I/O and other things - but of different releases of these modules. (At least one of those SW was IBM's.) And other cases. Did you try putting the then-current SAS/C release in linklist? If that didn't work, you could have opened a problem report with SAS and we would have tried to fix it. For the WSA (back when it was written in SAS/C), we actually prefixed the library so that you could put two (or more) versions in linklist without disrupting running programs. This experience coupled by some recent contacts with development labs at IBM give me the impression that IBM lacks contact with the reality out here... ;) ? Regards, Thomas Berg _ Thomas Berg?? Specialist?? A M?? SWEDBANK -Ursprungligt meddelande- Fr?n: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] F?r Juergen Keller Skickat: den 25 januari 2012 09:51 Till: IBM-MAIN@bama.ua.edu ?mne: Re: PDSE Hello all, thank you for your updates and hints. Lets bring the discussion to an end ... The problem started when we began to install z/OS 1.12 and my colleagues did not want me to use dynamic steplib in the future (that was another post some month ago). So we decided to bring this load library to LNKLST. This worked fine for some weeks. No we wanted to install some maintenance to this library and this did not work as expected. The library is PDSE and from the posts I learned that we should not do what I wanted to do. So finally we decided to remove it from LNKLST and define it as a STEPLIB to the logon-procedure. That solves all the problems with lnklst and makes it much more easier to install maintenance. snip -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: SV: STEPLIB problems - was: PDSE
Thomas Berg wrote: -Ursprungligt meddelande- Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] För Don Poitras Skickat: den 25 januari 2012 13:11 Till: IBM-MAIN@bama.ua.edu Ämne: Re: STEPLIB problems - was: PDSE In article a90e503c23f97441b05ee302853b0e62616721c...@fspas01ev010.fspa.myntet.se you wrote: The original case by Juergen touches the main shortcoming of IBM's STEPLIB-stance. There are cases when putting steplib(s) in linklist simply do not work! And where the alternative of putting it in the logon procedures is working nearly as bad. I have several times seen those cases luckily (= allowed by management) been solved by dynamic steplib functions from outside IBM. This happens when You must use conflicting software or software versions. One such case was when we were upgrading DB2 and during that period was the different test/development DB2 systems on different release levels. Another case was when we had different software (in the TSO development environments) that relied on the same set of SAS/C modules for I/O and other things - but of different releases of these modules. (At least one of those SW was IBM's.) And other cases. Did you try putting the then-current SAS/C release in linklist? If that didn't work, you could have opened a problem report with SAS and we would have tried to fix it. For the WSA (back when it was written in SAS/C), we actually prefixed the library so that you could put two (or more) versions in linklist without disrupting running programs. IIRC, these SAS/C modules was delivered as a part of these SW's own libraries, not as a part of the SAS product. (I call these SAS/C as that was what I saw when browsing the loadmodules.) In fact, one of the SW's was ISPF/WSA and the other (IIRC) was a product called ProEdit. BTW, what do You mean by prefixed the library ? SAS/C != SAS. The SAS/C Transient Library contains portions of the C run-time library and is freely distributable by ISVs. We ask that they distribute it as provided, but we can't force them to do so. Back in '96, we worked with IBM to take advantage of a feature that was already present. In order to allow the CICS transient library to co-exist with the non-CICS version, the calling code was written to use a prefix for each load module. LSH for CICS and LSC for non-CICS. These names are actually aliases of the L$C prefix that we use for zapping the modules with maintanence. User programs would pick up the prefix by linking with the appropriate link library. For IBM, we externalized this feature and they started delivering the transient library with (as I recall) ISP as the prefix. The idea being that IBM wouldn't be forced to use a newer transient library (or back-level if the customer for some reason did that.) A few other ISV's used this as well. Regards, Thomas Berg _ Thomas Berg Specialist A M SWEDBANK -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: A design question
In SAS/C, we implemented this functionality (handling START/STOP/MODIFY) using a signal. It seemed a natural fit for C. http://support.sas.com/documentation/onlinedoc/sasc/doc750/html/75chgs/z2474017.htm McKown, John wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tony Harminc Sent: Tuesday, January 03, 2012 5:38 PM To: IBM-MAIN@bama.ua.edu Subject: Re: A design question On 3 January 2012 14:28, McKown, John john.mck...@healthmarkets.com wrote: This is what you need to get familar with: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/EDC LB1B0/3.138 quote General Description Used to communicate with the operator's console. The __console2() function allows users to send messages to the operator's console with the ability to specify routing codes and message descriptor codes, wait on a modify/stop request from the console, and to delete messages from operator console using either message IDs or tokens. /quote The serious problem with __console2() is that it steals from your MODIFY namespace. If you use it, you can't aim general commands at your program in the usual and expected way f proc,command but rather, you have to use f proc,appl=command If you issue the normal version, you will be rewarded with BPXM022E MODIFY SYNTAX ERROR; command WAS FOUND WHERE ONE OF THE FOLLOWING WAS EXPECTED: APPL= TERM= FORCE= SHUTDOWN= RESTART= DUMP= FILESYS= RECOVER= SUPERKILL= This is one of those unfortunate decisions made back when UNIX System Services (shall we call it USS for short?) was being implemented, and it's too late to fix it in a compatible way. However to the extent that pthreads are MVS tasks, you can continue to use your assembler routine. Tony H. Very true. I made the assumption that the OP wanted to totally eliminate HLASM in favor of C. Assembler, or Metal C perhaps, is a better choice for operator communications. -- John McKown Systems Engineer IV IT -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDS Command - 40 Years Old
John P Kalinich wrote: The PDS command is still running today in the z/OS environment. Tom Springer, Steve Smith, and William Finkelstein were the original authors 40 years ago when they worked together at Security Pacific National Bank. Bruce Leland and Steve Smith took the PDS command to a new level after developing the StarTool® vendor product. And Sam Golob (Mr CBT) deserves a lot of credit for publishing numerous articles about how to use the PDS command. It's a great program. I wish the support for PDSE that was introduced included mapping the entire program object rather than just the B_TEXT segment though. As it is, I still need to use AMBLIST for program objects. Best Regards, John K Download at http://www.cbttape.org/ftp/updates/CBT182.zip I guess that's old. Current link is: http://www.cbttape.org/ftp/cbt/CBT182.zip -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDS Command - 40 Years Old
John P Kalinich wrote: Don Poitras of the IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu wrote on 01/03/2012 09:16:02 AM: It's a great program. I wish the support for PDSE that was introduced included mapping the entire program object rather than just the B_TEXT segment though. As it is, I still need to use AMBLIST for program objects. AMBLIST is now a PDS subcommand. Regards, John K )F Example - AMBLIST mema:memb The AMBLIST subcommand invokes the IBM AMBLIST program to list a load module map, cross-reference map, and CSECT identification records (IDR). The system's pasta maker. . . take a lump of dough, send it through AMBLIST, and you come out with beautiful spaghetti! )X SYNTAX - AMBLIST memgroup ALIASES - AM, AMB, AMBL, AMBLI, AMBLIS, ABMLIST DEFAULTS - none. REQUIRED - memgroup. Thanks. I hadn't seen that. It's almost useless for large modules though. You need to keep hitting '0' to continue the display and after a while the top of the listing rolls off. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PDS Command - 40 Years Old
Mark, That's somewhat better. Only 4 '0's required. Still lost the top of the listing though. I used the max of 64000 lines, but the AMBLIST of the module I'm looking at produces 123000 lines. I suppose I could figure out where in the source this limit is set, but it's just not that big a deal to run AMBLIST in JCL for me. For smaller modules, the AM rather than MAP will come in handy though. Thanks. Mark Zelden wrote: On Tue, 3 Jan 2012 11:27:49 -0500, Don Poitras sas...@sas.com wrote: You need to keep hitting '0' to continue the display and after a while the top of the listing rolls off. A little PDS training is in order... :-) Try the SETLOG command. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: z/OS 1.13 ASCENV incompatible change in Assembler
Barry Merrill wrote: So the bottom line is that nothing has changed except our need to do something for no reason at all. We only had to add 431 SYSSTATE calls to 64-bit SAS. :) -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: PS file record Delete - Query
You could also copy the file and omit the line. TSO REPRO with COUNT and SKIP options. In article CANHhCyQ06NzXvURCZMKEa2Z6G34_suqNFRA1dwp=1qugfjd...@mail.gmail.com you wrote: Hi, Just looking to delete the intended lines using ISPF Edit Macro(Lets say line 2 to be deleted without a D command). Jags On Mon, Nov 28, 2011 at 10:45 AM, jagadishan perumal jagadish...@gmail.comwrote: Hi, Apology I am just trying to achieve it via : TSO/ISPF. Jags On Mon, Nov 28, 2011 at 10:40 AM, Lizette Koehler stars...@mindspring.com wrote: Hi, We have a PS file record where we have more than 1000 records. Just of of curiosity is it possible to delete a selected line without using D tso command. Objective behind this deletion is just to make sure the deletion is just done without disturbing anyother Lines. Tried Googling to find if there are any TSO tricks to do the same but not able to get the one. Any suggestions or ideas are much appreciated. Jags Jags, Yes, write a BSAM program and either count to the record you want or search till you find the record you want. The question is How to program the process to do what you want. You do not say if you are trying to do the interactively (ISPF or TSO - CLIST or REXX) or through a batch program. You can use REXX, ISPF MACRO, Assembler, Cobol, etc... It all depends on what you are trying to do. What are the parameters that you would use to decide which record to delete? Then build the process to do that. Lizette -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: RMODE and AMODE at 24 - Query
Severity 4 is just a warning. In this case, you can ignore it. It's just telling you that it found an AMODE=31 directive in the source and you are now overriding it. If you fix the source, you'll get rid of the LKED note. Or you can specify COMPAT=LKED to get rid of the message. jagadishan perumal wrote: I included AMODE(24) RMODE(24) at the step LKED and it was getting compiled with AMODE as 24 and RMODE as 24. Unfortunately the Job ended with Severity of 04 saying the ESD AMODE 31 CONFLICTS WITH USER-SPECIFIED AMODE 24 FOR ENTRY POINT TRNM007. Let me post this question to CICS newsgroup Jags On Wed, Nov 9, 2011 at 5:34 PM, Lizette Koehler stars...@mindspring.comwrote: Hi, Below is my JCL where I want to compile my MAP load module at RMODE-24 and AMODE - 24, but the Load module is getting created with AMODE-31,RMODE-ANY. You may wish to post on the CICS newsgroup and see if a BMS map can be 24 and how to do that. They should be able to help. Also see what is generated in your assembler step. There might be some MODE statements (AMODE or RMODE) in the CICS macros. Review your LKED control cards. They also might provide an area to research. Lizette -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C newbie - pass a LDAP handle out to calling routine
Dave, You need to cast to a pointer type that memcpy (or whatever) can handle. e.g. memcpy(foo, *((char *) ld), 10); If you want to use this a lot, it might be better to just copy to a pointer of another type: char *bar; bar = (char *) ld; memcpy(foo, *bar, 10); Also, I find it beneficial to display addresses in hex. e.g. printf(ld before bind :%08X\n,ld); In article 0de6a9840123e547b061ac5b6765c0261c1...@exmb-05.ad.wsu.edu you wrote: This is my first experience with C, but a language is a language after the 3rd or 4th :) I'm calling C for LDAP queries from Natural (Software AG 4GL) in batch. And it works, sort of. One FM is IBM Tivoli Directory Server Client Programming for z/OS If I use the sequence ldap_init, ldap_simple_bind_s, ldap_search, ldap_unbind, it gets overloaded after 5 calls at the speed of batch. If I leave out the unbind, it works for thousands of calls, but there is an obvious memory leak. So, I want to anchor the ldap handle in the main driving program. I made a simple C stub: extern int ret2nat (int *back_value, LDAP *ld, char *msg) #include ldap.h In ldap.h there is: typedef struct ldap LDAP; The examples use: LDAP * ld; To declare an ldap_handle which according to the listing is an: ld 6270-1:1931 Class = parameter, Length = 4 Type = pointer to incomplete struct ldap I have a function: LDAP * bind_adlds(char *hostname, char *container, char *msg) And I call it: printf(ld before bind :%d\n,ld); /* ld before bind :286352012 ld = bind_adlds(hostname, container, msg) ; printf(ld after bind:%d\n,ld);/* ld after bind :283317144 but the value is not returned to the caller of ret2nat. Any attempts to use *ld in an assignment or even memcpy() get a complier message: ERROR CCN3285 /u/ldap/test.c:46The indirection operator cannot be applied to a pointer to an incomplete struct or union. Or WARNING CCN3068 /u/ldap/test.c:46Operation between types int* and pointer to an incomplete type is not allowed. As I said, I am just learning how to spell C. I know I am fighting some kind of battle of types. I welcome even derisive comments, if in the end thay help. Dave Gibney Information Technology Services Washington State University -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C newbie - pass a LDAP handle out to calling routine
Sorry, memcpy was a bad example. The parms to that are pointers, not dereferenced pointers. memcpy(foo, ld, 10); didn't work? I guess that's something to do with incomplete type. I'm not familiar with that. My suggestion still sort of stands though. Try: memcpy(foo, (char *) ld, 10); and for the 2nd example: memcpy(foo, bar, 10); In article 2004225459.dda808f...@panix3.panix.com you wrote: Dave, You need to cast to a pointer type that memcpy (or whatever) can handle. e.g. memcpy(foo, *((char *) ld), 10); If you want to use this a lot, it might be better to just copy to a pointer of another type: char *bar; bar = (char *) ld; memcpy(foo, *bar, 10); Also, I find it beneficial to display addresses in hex. e.g. printf(ld before bind :%08X\n,ld); In article 0de6a9840123e547b061ac5b6765c0261c1...@exmb-05.ad.wsu.edu you wrote: This is my first experience with C, but a language is a language after the 3rd or 4th :) I'm calling C for LDAP queries from Natural (Software AG 4GL) in batch. And it works, sort of. One FM is IBM Tivoli Directory Server Client Programming for z/OS If I use the sequence ldap_init, ldap_simple_bind_s, ldap_search, ldap_unbind, it gets overloaded after 5 calls at the speed of batch. If I leave out the unbind, it works for thousands of calls, but there is an obvious memory leak. So, I want to anchor the ldap handle in the main driving program. I made a simple C stub: extern int ret2nat (int *back_value, LDAP *ld, char *msg) #include ldap.h In ldap.h there is: typedef struct ldap LDAP; The examples use: LDAP * ld; To declare an ldap_handle which according to the listing is an: ld 6270-1:1931 Class = parameter, Length = 4 Type = pointer to incomplete struct ldap I have a function: LDAP * bind_adlds(char *hostname, char *container, char *msg) And I call it: printf(ld before bind :%d\n,ld); /* ld before bind :286352012 ld = bind_adlds(hostname, container, msg) ; printf(ld after bind:%d\n,ld);/* ld after bind :283317144 but the value is not returned to the caller of ret2nat. Any attempts to use *ld in an assignment or even memcpy() get a complier message: ERROR CCN3285 /u/ldap/test.c:46The indirection operator cannot be applied to a pointer to an incomplete struct or union. Or WARNING CCN3068 /u/ldap/test.c:46Operation between types int* and pointer to an incomplete type is not allowed. As I said, I am just learning how to spell C. I know I am fighting some kind of battle of types. I welcome even derisive comments, if in the end thay help. Dave Gibney Information Technology Services Washington State University -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for clues on a bug in assembler
In article 072a01cc8bbd$e0a71d70$a1f55850$@mcn.org you wrote: PSW. 078D1400 995E254A Ok. AMODE=31 Can you branch to 195E25xx if you're in AMODE 24? Yes. The 19 is ignored. You'd actually be at 005E25xx. Just as the high bit is ignored for AMODE=31 in this case. If your PSW was 078D1401 8000 995E254A, you'd be branching to 995E254A. The address part of the PSW needs the amode bits to be meaningful. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Don Poitras Sent: Saturday, October 15, 2011 5:44 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Looking for clues on a bug in assembler In article 071a01cc8b8e$9956ef10$cc04cd30$@mcn.org you wrote: Thanks, John. Let me take those in reverse order. It might also be possible that you go thru File 'B' in the wrong AMODE. I would be the first to admit I am only about 98% on top of every 24- vs. 31-bit addressing consideration but seeing as how all of the action both good and the S0C4 is taking place around 19xx I think I must be -- as desired -- in 31-bit AMODE. What do the amode bits in the PSW say? If you're looking at a short format PSW, 19xx is amode 24. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Looking for clues on a bug in assembler
In article 071a01cc8b8e$9956ef10$cc04cd30$@mcn.org you wrote: Thanks, John. Let me take those in reverse order. It might also be possible that you go thru File 'B' in the wrong AMODE. I would be the first to admit I am only about 98% on top of every 24- vs. 31-bit addressing consideration but seeing as how all of the action both good and the S0C4 is taking place around 19xx I think I must be -- as desired -- in 31-bit AMODE. What do the amode bits in the PSW say? If you're looking at a short format PSW, 19xx is amode 24. -- Don Poitras -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Any 3270 emulators for Mac Lion?
Cheryl, I downloaded the beta from Brown and it seems to work fine on my home Lion Mac Mini. http://www.brown.edu/cis/tn3270/tn3270_X_3.3b6.dmg I believe I'm using all the default settings. I pick the mod-4 screen format when it comes up. In article c7145c2e-a9e3-40a3-9910-8538829d8...@watsonwalker.com you wrote: I upgraded to Lion on my Mac and I can't find a 3270 emulator that works. (My old emulator stopped working after the upgrade.) I've downloaded two or three that say they're for Lion, but I can't get them working. If you've had success, please let me know (and maybe tell me what settings you use)? Thanks, Cheryl == Cheryl Watson Watson Walker, Inc. www.watsonwalker.com == -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: UNIX (USS)
When driving your Cessna on the freeway, you must steer with your feet. Turning the yoke won't do much. :) Paul Gilmartin wrote: On Mon, 22 Aug 2011 14:21:19 -0500, Rozeboom, Kay [DAS] wrote: I have just finished learning UNIX basics using a wonderful book called UNIX for the Mainframer by David B. Horvath. It is a bit out of date, but almost everything still applies. He takes the approach of, If you know how to do X on MVS, here is how you do it in UNIX.. I found the part on writing shell scripts so that they resemble JCL to be especially helpful. I agree with John M. here. If you write shell scripts to resemble JCL. you'll never get any better than JCL. Kind of like driving a Cessna on the freeway: Move the control column from side to side to steer; just never try pulling it toward you! The tragedy is that when I know how to do something in a shell script there's rarely a way to do it in JCL. Or in TSO. But, are there any examples of shell-script-looks-like-JCL that might be posted here (within Fair Use, of course). -- gil -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Co: Z Toolkit for z/OS Install
Mark Zelden wrote a nice REXX program to show memory. You can run under TSO or TSO OMVS (or on a native shell session.) http://www.mzelden.com/mvsfiles/rexxstor.txt Kirk Wolf wrote: Randy, See our latest response to your thread on our free support forum here: http://dovetail.com/forum/viewtopic.php?f=8t=1133 (Someone here may have a suggestion as to how to diagnose region size under TSO OMVS... it would be nice if there was a simple way to display available region size from the LDA while in TSO OMVS). Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Aug 10, 2011 at 9:31 AM, Randy Hoekstra randy.hoeks...@haworth.comwrote: I'm trying to install the Co: Z Toolkit for z/OS under TSO OMVS and can't get around the FSUM9225 no memory: EDC5132I NOT ENOUGH MEMORY. errors with a TSO region size of 2047M. Our test system CSA = 2404K, ECSA = 61588K. Any suggestions? -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Co: Z Toolkit for z/OS Install
Mark, While I'm looking at this, there is one odd aspect I'd like to understand. Maybe you know this. Even though the LDA shows the region (LIMIT and SIZE) as coming from TSO when run under TSO or TSO OMVS and RACF OMVS segment when run under the native shell, I'm not sure where region requested is coming from. I have ASSIZEMAX=0536870912, but the value that shows up both under TSO OMVS and the native shell as: Region requested: 55296K Perhaps this is set through some exit, but I thought it was strange as I actually get the region size I expect, but this value is much lower. When I run your exec on native TSO, the value is what I expect to see: 1048576K. I'd expect on TSO OMVS to see the same value and on native shell to see 524288K. Mark Zelden wrote: Which was how I originally determined what Kirk wrote about where the region size came from for TSO OMVS (and ISHELL).But it is also documented somewhere in the manuals. Using my exec was just a lot easier than trying to find where it is documented. :-) -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ On Wed, 10 Aug 2011 13:02:44 -0400, Don Poitras sas...@sas.com wrote: Mark Zelden wrote a nice REXX program to show memory. You can run under TSO or TSO OMVS (or on a native shell session.) http://www.mzelden.com/mvsfiles/rexxstor.txt Kirk Wolf wrote: Randy, See our latest response to your thread on our free support forum here: http://dovetail.com/forum/viewtopic.php?f=8t=1133 (Someone here may have a suggestion as to how to diagnose region size under TSO OMVS... it would be nice if there was a simple way to display available region size from the LDA while in TSO OMVS). Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Aug 10, 2011 at 9:31 AM, Randy Hoekstra randy.hoeks...@haworth.comwrote: I'm trying to install the Co: Z Toolkit for z/OS under TSO OMVS and can't get around the FSUM9225 no memory: EDC5132I NOT ENOUGH MEMORY. errors with a TSO region size of 2047M. Our test system CSA = 2404K, ECSA = 61588K. Any suggestions? -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: C compiler issue
You can expand the headers in the listing by adding the SHOW compiler option. In article 3910630036250514.wa.henrique.seganfredobcb.gov...@bama.ua.edu you wrote: Hello, I?ve been trying to compile a C CICS program that uses sockets. After the translation with DFHEDP1$ (ends with RC=00) the program is compiled with CCNDRVR. For my surprise, the compiler starts complaining the folllowing: ..(CICS definitions put by the translator)... 56 |/* #pragma pack(packed)*/ 57 |#define _TCP31_PROTOS 58 |#define _OE_SOCKETS 59 | 60 |#include manifest.h *=WARNING= CCN3234 Expecting a new-line character on #ifdef directive. *=ERROR=== CCN3166 Definition of function a requires parentheses. *=ERROR=== CCN3191 The character # is not a valid C source character. *=ERROR=== CCN3191 The character # is not a valid C source character. ... *=ERROR=== CCN3766 The universal character name is not in the allowable range *=ERROR=== CCN3766 The universal character name is not in the allowable range ... Any idea? Seems some control chars are put or deleted and end up messing with the file. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: TCPIP Resolver Question
Anson, Normally it's at SYS1.TCPPARMS(TCPDATA), but you can name it whatever you want if you point to it via DD name or environment variable. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3a0/1.5.2.2 Anson Ye wrote: Hi All, I'm reading some tcpip document about resolver.. I'm curious what system will do if I don't configure the resolver settings explicitly. According to the IBM book library, if I don't specify the resolver process in the BPXPRMxx, the system will start up the resolver address apce with name of 'RESOLVER' but without global tcpip data settings. The z/OS will use the applicable searching order for finding TCPIP.DATA. Now comes out the question, what's the 'applicable searching order'? Thanks! Best Regards! Anson -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: HOWTO question: Linking non-XPLINK C with a shared object (.so) library
Peter, Did you supply the DLL compiler option? Usually, it's better to just include the DLL side file (/usr/lib/iewbndd.x) rather than trying to write all these yourself. Remember at runtime, you must set LIBPATH to be able to find the DLL. Farley, Peter x23353 wrote: I do not want to mix XPLINK and non-XPLINK code, I want to write non-XPLINK C code to use the non-XPLINK shared-object API subroutines. IBM supplies both an XPLINK shared-object file (iewbnddx.so) AND a non-XPLINK shared-object file (iewbndd.so). IBM provides sample JCL showing how to use only the XPLINK shared-object file. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Miklos Szigetvari Sent: Wednesday, July 13, 2011 5:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: HOWTO question: Linking non-XPLINK C with a shared object (.so) library Hi Don't understand why do you want to link together XPLINK and NON XPLINK code, and not call the DLL. The boundary for XPLINK NON XPLINK code is a DLL, so a DLL is XPLINK or not. In SHARE there was a number of very good presentations about the DLL's and XPLINK -- -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Knuth's latest release
Yes. The binding is pretty bad. That section is just loose in my version, but at least it's there. Yours must have fallen out and nobody noticed. In article 4e03872e.1050...@ync.net you wrote: I ordered Knuth's latest volume, Combinatorial Algorithms from AMAZON some time ago and have only now cracked it open. Imaging my surprise when the first page containing anything useful was page 15. What happened to the table of contents, etc. ?? Anyone else have the same experience ?? Rick -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How to diagnose memory leak?
Victor Gil wrote: Hi, We have an Assembler user exit invoked by a software product that runs as a long-running batch job. The exit properly OBTAINs and RELEASEs its working storage, however, as written it does not handle a non-zero return code from the STORAGE OBTAIN. This hasn't been a problem up until last week when it began to abend and the dumps indicate that there was not enough memory to allocate. Obviously, there is some sort of memory leak in the address space. Or something changed to require a larger REGION. Any tips on how to identify the cause are greatly appreciated. -Victor- Use IPCS to inspect the dump. ip VERBX VSMDATA 'NOG SUMMARY' will produce a nice report. Scroll down to: LOCAL SUBPOOL USAGE SUMMARY TCB/OWNER SP# KEY BELOWABOVETOTAL - --- --- --- If one particular TCB seems to be using the lion's share of the storage, inspect some of the allocations. Look for: Data for TCB at address ... DQE: Addr Size 1000 Look at that address in the dump and hopefully find some eyecatchers that will identify the culprit. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Problem with resolving own host name
Moribund or not, you're paying for support. Why not use it? My guess is that you're using the SAS/C resolver and you should switch to the IBM resolver. Contact SAS tech support or just read the manual to see how to do that. In article 2055c4ebc2b05442853ca436c40652851bcd5...@nwb-exchange.microfocus.com you wrote: Chris - Thanks for the response. Since I posted I have tried running hometest, telnet, with the trace and they do gethostbyname() without problems, so I am inclined to think the problem lies with the SAS/C runtime. Unfortunately SAS/C is no longer marketed and is basically a bit moribund, so I don't expect any help from that quarter. By host name I indeed meant the system name; it turns out that fully qualifying that with the domain circumvents the problem, so I suggested that to the customer as a work-around. I will check-out the IBMTCP-L list, however. Cheers -Robin -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Chris Mason Sent: 27 May 2011 15:02 To: IBM-MAIN@bama.ua.edu Subject: Re: Problem with resolving own host name Robin I see you have not had a response to this. Please be aware that the greatest concentration of IP-based expertise is in IBMTCP-L: For IBMTCP-L subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO IBMTCP-L Turning on the resolver trace shows the host name getting resolved correctly, it just doesn't reach the application. We are using SAS/C R750 compiler and runtime. Given that the resolver trace is as expected, it looks like a problem at the level of the API. What do SAS C R370 say the problem might be? We have an application on z/OS 1.11 that reads in its unqualified host name from a config member Incidentally, just to be clear, this unqualified host name from a config member is presumably a gethostname() call so that the string returned is the typically single token corresponding to what is specified in the generically named TCPIP.DATA data set HOSTNAME parameter, default the VMCF parameter name or, failing that, the MVS system name. Chris Mason On Thu, 26 May 2011 17:00:32 +0100, Robin Atwood robin.atw...@microfocus.com wrote: We have an application on z/OS 1.11 that reads in its unqualified host name from a config member and resolves it via an external DNS server by calling gethostbyname(). This works as expected if the TCPIP.DATA config contains a DOMAINORIGIN statement. If we change the DOMAINORIGIN to a SEARCH statement, specifying our domain name first in the list, gethostbyname returns null. This was first reported by a customer and I can it duplicate it here. Turning on the resolver trace shows the host name getting resolved correctly, it just doesn't reach the application. Fully qualifying the host name in the config member gives the right result. We are using SAS/C R750 compiler and runtime. TIA -- Robin Atwood This message has been scanned by MailController - portal1.mailcontroller.co.uk -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How Mainframe Startup Screen Works
I guess I'm missing your point. The OP wanted to know where the logon screen source is and what VTAM commands it would need to produce it. I think showing a sample of the source is exactly what he wanted. I uploaded the sample and there are no assembler errors. I'm especially pleased that some of the parms say FORMAT=BAL. :) Chris Mason wrote: Don This looks like a template for people who might want to tackle actually building USS commands and USS messages. As it stands, as far as USS messages are concerned, it is worse than useless since it is misleading. There are examples of USSMSG macros with the TEXT operand specified. There are data areas defined which beg to be named in an USSMSG with the BUFFER operand but this is mutually exclusive with the TEXT operand. A picture is worth a thousand words. But it's better when they don't lie! I tried to see if any help was available but, back at the home page I discovered - and I'm doing this without references so German-speakers please forgive me - wenn man Deutsch spricht dann geht es weiter! Chris Mason On Tue, 10 May 2011 11:23:47 -0400, Don Poitras sas...@sas.com wrote: A picture is worth a thousand words. Scroll down to MSG10S: http://www.sssgmbh.de/download/zos/sysp.usersrc/ussrole To decode the 3270 bits, look here: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How Mainframe Startup Screen Works
A picture is worth a thousand words. Scroll down to MSG10S: http://www.sssgmbh.de/download/zos/sysp.usersrc/ussrole To decode the 3270 bits, look here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/CN7P4000/CCONTENTS hase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Hal Merritt This is called the 'USS Table' or Unformatted Screen Services (I think). It is a BAL program using macros supplied with the VTAM product. The program source could be anywhere; ask your VTAM guy if you have one or general sysprog if you don't. The executable can reside in a number of different system load libraries. Again, ask your VTAM person or sysprog. More precisely it's the 'USSMSG10 screen', a part of Unformatted System Services. There is usually one for each type of hardware terminal supported. It is a table, as it is most often used to take arbitrary entries and execute the VTAM commands necessary to invoke an application. Here ITYM the USSCMD table. By the way, that initial z/os screen seems to have become known as a 'green screen'. Indeed, the 'mainframe interface' generally is known as 'green screen'. -jc- -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Floating point assembler code
I gave up TSO TEST for ASMIDF years ago. Give it try. In article listserv%201104051934476841.0...@bama.ua.edu you wrote: On Tue, 5 Apr 2011 15:36:24 -0400, Tony Harminc t...@harminc.net wrote: I too continue to use TSO TEST for certain things, and indeed it would be a very good thing if they would add just a few little updates: Better floating point support, as you suggest Access register support 64-bit GPR support 64-bit indirection (the IPCS syntax would be consistent) TEST (and other TSO components) are extra frustrating because however dead-ended TSO may be, there *are* updates going on, but they never seem to take the opportunity to make minor enhancements while they have a module open for other purposes. Yeah, I know - internal politics, time budget allocation, and so on. But most development labs manage to sneak in a few enhancements under the RADAR from time to time. Yes, I've discussed some of those with the TSO guy. The basic problem with all of them seems to be that they hit the TSO TEST register save and restore processing and that is non-trivial to upgrade plus its hard to do piecemeal. I've done a fair amount of AMODE(64) testing on TEST and it seems to run AMODE(64) stuff just fine; its just that you can't see the addresses when they're in registers... :-( Writing the code is the easy part; its getting the resources to thoroughly test what you've written that stops you dead in your tracks. W. Kevin Kelley -- IBM POK Lab -- z/OS Core Technical Development -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DOWNLOADING PDS FROM MAINFRAME TO PC
Use nmap. e.g. prompt case nmap $1 $1.txt mget * Do the opposite for uploading. i.e. nmap $1.$2 $1 Craig Pace wrote: I agree with the XMIT only because of file space that is saved; however, you can download it a empty directory on your PC with the FTP MGET option and then run a batch program (anything.BAT) that simply does a RENAME x:\path\* x:\path\*.txt and it will rename all files to have the .txt extention. I have used this before when wanting to be able to directly read files are in the PC world and automatically open it up in a Text viewer; for example, program source code. Thanks, Craig Pace z/OS Systems Programmer Fruit of the Loom, Inc.® Office: (270) 781-6400 ext. 4397 Cell: (270) 991-7452 Fax:(270) 438-4430 E-mail: cp...@fruit.com One Fruit of the Loom Drive PO Box 90015 Bowling Green, KY 42102-9015 Rob Schramm rob.schr...@gmail.com Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu 01/17/2011 01:28 PM Please respond to IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu To IBM-MAIN@bama.ua.edu cc Subject Re: DOWNLOADING PDS FROM MAINFRAME TO PC Willie, Unfortunately, mget doesn't work like that... you can specify multiple filenames and use the file* .. but cannot change the name on the mget. I have to agree with the other poster about using XMI for the whole PDS. But in this case, once you are done with the mget, you should be able to run a cmd line from the directory in question and run a rename * *.txt BTW, mput has the same set of restrictions. Rob Schramm -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: h_errno undefined
Global externals are resolved differently for XPLINK or regular compiles. You probably just need to add SCEEOBJ to your autocall libs. See this: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/cbcug190/A.12 Charles Mills wrote: No. As I said, I coded exactly what the IBM reference suggested. Is h_errno related to errno.h? I did not think it was. The documentation for each would seem to suggest that they are unrelated. Charles -Original Message- From: MVS OpenEdition [mailto:mvs...@vm.marist.edu] On Behalf Of David Bruton Sent: Monday, January 10, 2011 7:49 AM To: mvs...@vm.marist.edu Subject: Re: [MVS-OE] h_errno undefined Are you including errno.h ? -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Linking Code from z/OS Unix archives in Batch JCL?
Instead of INCLUDE, use LIBRARY. e.g. LIBRARY /shr/openssl/lib/libcrypto.a LIBRARY /shr/openssl/lib/libssl.a In article 4d1e17c6.4020...@t-online.de you wrote: Is it possible to link code directly from z/OS Unix archive files? I tried it this way: //LKED EXEC PROC=WCIEWL, // AMODE=31,RMODE=ANY,REUS=RENT, // SYSLMOD='ADPSAE.LEHR.GRP20.LOAD', // SYSOUT=A, // SYSLIN='TEMPDSN' //SYSINDD * INCLUDE '/shr/openssl/lib/libcrypto.a' INCLUDE '/shr/openssl/lib/libssl.a' NAME NWPDDR(R) /* but got the following error message: IEW2278I B352 INVOCATION PARAMETERS - ,,LIST,MAP,XREF,,RENT,AMODE=31,RMODE=ANY IEW2322I 1220 1INCLUDE '/shr/openssl/lib/libcrypto.a' IEW2339S 1035 THE INCLUDE DATA SET SPECIFIED BY DDNAME /001 IS AN ARCHIVE FILE. IEW2322I 1220 2INCLUDE '/shr/openssl/lib/libssl.a' IEW2339S 1035 THE INCLUDE DATA SET SPECIFIED BY DDNAME /002 IS AN ARCHIVE FILE. IEW2322I 1220 3NAME NWPDDR(R) It is obviously possible for object files (*.o). Is there a simple way to get the needed objects from the archives, without having to specify the names of the functions? I'd like to stay with JCL processing, for several reasons. Kind regards Bernd -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tar limitation preventing SAS install
In article 4d1bf072.1000...@gmail.com you wrote: On 30/12/2010 8:02 AM, Paul Gilmartin wrote: You can make a tarball on Windows? With what utility? (Not that that would be meaningful to me.) When you list the directory of that tarball, are the pathnames truncated or intact? If intact, the problem is on the z/OS side (or a compatibility problem). NFS? Would your admins be delighted? Question applies alike whether or not you're the admins. Hmmm. You could install VirtualBox for free on the PC: http://www.virtualbox.org/ (Disclosure: it's my employer's product) ... and install Ubuntu Linux under VirtualBox, and mount your tree and/or tarball as a folder shared between Windows and Ubuntu and play with that. Or you could just install cygwin and get all the nice linux goodies as native windows apps, including tar. On the higher-level versions of Windows 7 (above Home Premium) you can also download SUA (Subsystem for UNIX-based Applications.) This is the Microsoft version of what was Interix. Microsoft bought the company in 1999. I've been using SUA and before that SFU for many years now and find it pretty much the same as Cygwin. I don't know that tar handles long directory names, but I'd be surprised if it didn't work the same as on a native UNIX system. The base install is done via control panel and then you download utilities separately. http://technet.microsoft.com/en-us/library/cc771672.aspx -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: tar limitation preventing SAS install
In article listserv%201012292217099289.0...@bama.ua.edu you wrote: On Wed, 29 Dec 2010 22:52:26 -0500, Don Poitras wrote: In article 4d1bf072.1000...@gmail.com you wrote: Or you could just install cygwin and get all the nice linux goodies as native windows apps, including tar. On the higher-level versions of Windows 7 (above Home Premium) you can also download SUA (Subsystem for UNIX-based Applications.) This is the Microsoft version of what was Interix. Microsoft bought the company in 1999. I've been using SUA and before that SFU for many years now and find it pretty much the same as Cygwin. I don't know that tar handles long directory names, but I'd be surprised if it didn't work the same as on a native UNIX system. The base install is done via control panel and then you download utilities separately. http://technet.microsoft.com/en-us/library/cc771672.aspx Has this been tested and shown to work as an installation method for SAS 9.2? If not, another approach is needed. Is this documented as a prerequisite for installing SAS 9.2 from the given medium? If not, the installation instructions need to be updated. In fact, customers who purchased SAS 9.2 without being apprised of this prerequisite are victims of deceptive marketing and ought to be entitled to be reimbursed for the cost of obtaining the higher-level version[s] of Windows 7. In the longer view, I'd be dismayed that Windows, a fortiori a particular level of a particular version of Windows, should be a prerequisite for installing any mainframe product. Got me. I was just saying there's a native tar on Windows. -- gil -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: tar limitation preventing SAS install
Happy New Year! In article listserv%201012280016100756.0...@bama.ua.edu you wrote: On Mon, 27 Dec 2010 23:39:33 -0600, Arthur Gutowski wrote: SARCASM If you really want to have some fun, you should try their internet delivery. /SARCASM Didn't IBM solve that problem with RECEIVE FROMNETWORK. But SAS doesn't believe in SMP/E. But I have no cause to boast. My employer won't let me use that protocol as a supplier, and only with difficulty as a client. (Suggestion to IBM: extend RECEIVE FROMNETWORK to support HTTP[S] as an alternative to FTP.) The vendor's leaving processing to the customer on an unspecified platform using uncontrolled utilities is rife with hazards. At best, it introduces undocumented prerequisites. You ain't just whistlin' Dixie... XWindows, Java levels (PTF-sensitive, even)... to quote Dogma: 'It *never* ends!' Could the OP try building the tar archive on a Linux or OS X or anything but Windows system? If I read it correctly, the tar is as-distributed on the DVD, so if that was not built properly to begin with, windoze is the only drop for the untar. Then I read it otherwise. From the OP: On Sun, 26 Dec 2010 17:50:47 -0800, Schwarz, Barry A wrote: If anyone has installed SAS 9.2 using a PC to read the DVDs followed by using tar to prepare the depot for ftp to the mainframe, ... you'd either have to NFS-mount that filespace somewhere, or transfer the entire kit and kaboodle to re-tar it properly. FWIW, once you have the untar, you might as well just ftp it up to a z/OS Unix filesystem - just make sure your ftp client can process the whole tree and preserve the long path and file names. It took me a few failed installs before I realized that I forgot to check the box and some file buried *deep* in the tree lost part of its identity. Is the package delivered as a *.zip? If so, could it be transmitted as a BLOb to z/OS and unpacked with the jar command? If not, SAS has missed another opportunity. FWIW, SAS tells me they are working on improvements to the process. Apparently, I'm not the only one who has raised a stink. Feels like a SEV2 to me. Perhaps not to SAS. Two regular contributors to this forum with SAS return addresses have been conspicuously silent on this thread. Properly; it's prudent to eschew controversy. But perhaps their employer could make an official statement. Even just Happy New Year. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Antwort: Re: tar limitation preventing SAS install
In article 20101228141815.630ed8f...@panix3.panix.com you wrote: Happy New Year! Sorry, I couldn't pass a setup like that. I don't think there's anyone at Sas that's satisfied with the current situation regarding installation on z/OS. Naturally, I can't get into the specifics, but I think it's safe to say that there are many conflicting goals when trying to create a system as complex as SAS has become. Over the years, more and more of the SAS system has been targetted at the newer platforms and this sometimes leads to the mainframe ending up as oh, and it needs to run on z/OS. And it better run there just as fast as Windows! Actually, it's pretty amazing the amount of code that is shared across the platforms and the number of Sas developers that don't even fully grok that their code runs there. Certainly, one size fits all hasn't worked for installs though. While I am fully comfortable using the newer unix facilities on z/OS (including X11), I probably wouldn't be if I hadn't had a job that required me to learn it all. Tech support sometimes gets overwhelmed as well. They would like nothing better than to send a tape and an IEBUPDTE job to load it. :) That said, I think we have some of the best tech support in the industry and if you feel you're not getting service, I would suggest you attempt to escalate your trouble ticket. Maybe you just got somebody on a bad day. We take CRP (customer reported problems) as our highest priority in development. Ahead of any new feature. I can't promise that this is going to be fixed immediately. I don't even work in that area. But I know that the people working on this are dedicated to producing an install experience that matches the experience of those actually using SAS to it's full, installed, potential. Feels like a SEV2 to me. Perhaps not to SAS. Two regular contributors to this forum with SAS return addresses have been conspicuously silent on this thread. Properly; it's prudent to eschew controversy. But perhaps their employer could make an official statement. Even just Happy New Year. -- gil -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 64 bit mode disabled
The question was, is there a business case for execution about 2G? If CICS isn't putting it's _data_ above 2G, then putting the code up there isn't going to help much. Could the executable size, even for a large CICS address space be more than a few hundred megabytes? Tom Harper wrote: Of course it's not all due to a lot of executable code. It's much more complex than that. Like most things in life, there are mixtures of causes. Changing CICS is going to take a lot of time and effort, and some work has obviously already been done. I personally believe the priority of 64-bit exploitation should have been much higher, but I'm certain the development team has pressure on it from lots of source. Tom Harper Neon Enterprise Software Sugar Land, TX -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Thursday, December 02, 2010 8:07 AM To: IBM-MAIN@bama.ua.edu Subject: Re: 64 bit mode disabled On Thu, 2 Dec 2010 06:01:38 -0800 Gerhard Adam gada...@charter.net wrote: :This was confirmed to me by a very senior, knowledgeable person at a large :manufacturing company in the Midwest. Originally, they had split CICS into :multiple regions for functional and operational reasons, but the number :grew from ten to over eight hundred because they kept running out of address :space for programs. :I tend to remain skeptical that 800 regions is the result excessive :executable program code. I agree. CICS has to start supporting overthebar_DSA and 64 bit mode. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name of IPCS exit data table
The only time I've messed with IPCSPARM was to get previous versions of CICS verbexits to work. For mapping structures, I just link into steplib and it works just fine: ASID(X'0249') ADDRESS(D0C0.) STORAGE Command === ip cbf x model(sgcbm)SCROLL === CSR D0C0 E5E2C3C2 F94BF3F0 40404040 D4E5E261 | VSCB9.30 MVS/ | D0D0 C5E2C140 E2D7F74B F14BF240 C9C2D440 | ESA SP7.1.2 IBM | D0E0 40404040 F2F0F9F4 40404040 F0F3C2F7 | 2094 03B7 | D0F0 F7C14040 F0F3C2F7 F7C14040 F0F3C2F7 | 7A 03B77A 03B7 | ** TOP OF DATA ** VSGCB: D0C0 +0004 SASV. 9.30 OPSYS MVS/ESA OPSYV SP7.1.2 +001C MACID IBM MMODL 2094 CPU0. 03B77A +0034 CPU1. 03B77ACPU2. 03B77ACPU3. 03B77A +004C CPU4. 03B77ACPU5. 03B77ACPU6. 03B77A.. I link SGCBM RMODE=24,AMODE=24, but I don't recall if that is required. Hardee, Charles H wrote: After you have coded, assembled and linked your model(s). Place the loadlib to where you linked it into the STEPLIB concatenation if you have the ability or, as others have already stated, place use TSOLIB to allocate it to your TSO session prior to invoking ISPF/PDF and subsequently IPCS. Once done, create or edit the BLSCUSER member in your IPCS Parm lib. In the BLSCUSER member, code a line as follows for each control block you have included in your model member. DATA STRUCTURE(SCA) MODEL(IDMSBLSQ) If you created BLSCUSER, then be sure to code an END statement: END The final point to remember is that the BLSCUSER must be high enough in the concatenation of IPCSPARM that it is found before any other BLSCUSER member is found since I believe there is a default (empty) member supplied during the IPCS product install. If you have other models being used, be sure to either copy them into your member, or update the existing BLSCUSER member with your models. BLSCUSER is only looked for and found once so it must be all inclusive with respect to what you want. Reference materials for the statements used in BLSCUSER can be found in the z/OS MVS Initialization and Tuning Reference manual. Good luck and good hunting, Chuck Charles Hardee CA technologies Sr Sustaining Engineer Tel: +1-952-838-1039 charles.har...@ca.com -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of michealbutz Sent: Saturday, November 20, 2010 6:10 PM To: IBM-MAIN@bama.ua.edu Subject: Name of IPCS exit data table Hi, This is a bit confusing when Creating an IPCS structure for a user control block using BLSQMFLD and BLSQMDEF seems Like you have catalogue the Load module to the exit data table ??? Would anyone know the name of this table the IBM documentation is very vague -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Name of IPCS exit data table
In article 001b01cb8910$6b44bca0$41ce35...@net you wrote: Hi, This is a bit confusing when Creating an IPCS structure for a user control block using BLSQMFLD and BLSQMDEF seems Like you have catalogue the Load module to the exit data table ??? Would anyone know the name of this table the IBM documentation is very vague Just assemble and link/bind the module into a PDS and allocate that to your TSO STEPLIB. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: SAS 9.2 ABEND S0C4 in z/OS 1/4?
Steve Comstock wrote: On 10/8/2010 1:08 PM, Bob Rutledge wrote: Shmuel Metz (Seymour J.) wrote: I'm getting ready for a z/OS upgrade from 1.4 to 1.10, and as part of that we[1] will be going from SAS 8 to SAS 9.2. SAS 9.2 works fine on z/OS 1/10, but we get an 0C4 trying to use it on our 1.4 system. I did notice that the 1.4 system is still ARCLVL=1 (ESA/390 mode), but don't know whether that is relevant. Has anybody seen anything like that before, and, if so, what was the resolution? [1] Well, I'm a consultant and don't know the institutional history. http://support.sas.com/resources/sysreq/hosts/zos/ Bob I think he meant the institutional history of his client, not of SAS. This isn't a link to history, but a link to supported OS level for our application releases. As shown, 9.2 requires z/OS 1.7 or later. -- Kind regards, -Steve Comstock -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: errno2 values
TSO EXEC 'SYS1.SBPXEXEC(BPXMTEXT)' '76650291' TCPIP JrTcpError: Tcp returned an error identified by the return code Action: Correct the error reported by the return code. Tony Harminc wrote: On 30 September 2010 12:43, Paul Gilmartin paulgboul...@aim.com wrote: On Thu, 30 Sep 2010 10:29:56 -0600, Lester, Bob wrote: I'm trying to troubleshoot an FTP issue. This is a snippet from the batch job. This is on z/OS 1.9. This job fails every morning, and when restarted with no changes, it works! This is not a dial type circuit . EZA2589E Connection to server interrupted or timed out. Receiving data EZA2590E recv error from receive_data - EDC5120I Interrupted function call. (errno2=0x76650291) EZA1475I Connection with 168.162.55.204 terminated EZA1735I Std Return Code = 20150, Error Code = 00010 I'm trying to decipher the errno2 value. Looking at: z/OS 1.9 C++ Run Time Library errno2 list, it doesn't follow the format of the above errno2. The Rexx SYSCALL strerror is quite effective at deciphering error_code/reason_code pairs. I don't know how errno2 maps onto this protocol. The right half of the errno2 is the reason code. Or is it the other way around... Regardless, the right half of that fullword (the 8 hex digits) is listed in places like SYS1.MACLIB(BPXYERNO) - be careful with hex vs dec. The left half is some sort of undocumented module identifier maintained by the kernel, and it is what strerror is using to produce the module name (and perhaps the suggested action). Assuming the REXX function is calling pfsctl() (BPX1PCT) the lookups for errno and errno2 are independent, i.e. you can supply any combination, even if they don't occur in real life. There are a few annoyances with the values themselves - errno2 of 0 means the errno value says all there is to say, which is fair enough, but there are other errno2 values that also mean that. I think this (X'0291') is one of them, since the explanation is 'Tcp returned an error identified by the return code'. There are also some other things hidden in certain errno2 values, such as return codes from allocation and the like. And I've read, but never seen, that the C/C++ RTL itself, and perhaps LE, can set values in there that are not defined by the kernel. Tony H. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Virginia DOT outage
In article 4c80381e.6050...@ync.net you wrote: If the process seems to be working smoothly, who checks results? And how? We had an incident in Illinois where a license plate number was re-assigned but the database wasn't updated because the plate already appeared in the database. An innocent man was killed by State Police because the previous holder of that number was a badly wanted felon that was characterized as Armed and Dangerous. You should have seen how fast the fertilizer hit the Westinghouse! But the worst damage was already done. 20-20 hindsight? Rick They weren't injured, but you have to believe they were pretty scared when the plane they were flying last Saturday was met by armed men screaming at them. The 'criminals'? John and Martha King. Known throughout the US for their many pilot training courses. Made the bad mistake of flying a plane with a tail number the same as one that had been stolen eight years ago. Different model Cessna, but I don't really blame the police for not knowing the difference. The fault was in not updating the database when the tail number was re-issued. http://www.avweb.com/newspics/galleries/marthaking-securitymistake/large/02.jpg http://www.avweb.com/avwebflash/news/John_Martha_King_Held_At_Gunpoint_203205-1.html -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Date formats
SAS uses lots of date formats. ISO 8601 is a good spot to look for a large list. http://support.sas.com/documentation/cdl/en/lrdict/63026/HTML/default/a003169814.htm http://en.wikipedia.org/wiki/ISO_8601 zMan wrote: How many different date formats are there? There's the hardware timestamp, in two forms (original, with the 2046 rollover, and the extended one -- what is that, a STCKE instruction?). There's something called an Oracle format date. There's some UNIX format that rolls over in 2034 or some such (tsk, with an epoch of 1970 -- they sure weren't planning ahead!), too. Not to mention yy/mm/dd, mm/dd/yy, dd/mm/yy, with 2- and 4-digit dates, varying separators (or no separators: mmdd et al.), with and without leading zeroes (when there are separators: today as 8/13/2010 vs. 08/13/2010). And of course (the misnamed) Julian format. Rexx has a few others, but they're conveniences, like the number of days this year -- I don't really consider that a date format, though it's useful sometimes. What others are there? I'm working on something that will flexibly handle dates, and while I'm not sure I'll handle every format possible, I'd at least like to make the decision based on a pretty complete set of possible formats. -- zMan -- I've got a mainframe and I'm not afraid to use it -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: remove() of PDSE member leaves PDS locked
Etienne Thijsse wrote: On Wed, 28 Jul 2010 00:33:10 -0500, Barbara Nitz nitz-...@gmx.net wrote: Can you show the ENQ that you're talking about? Reason I am asking is that I don't believe that you're faced with an ENQ. Rather, you are probably faced with a latch, as that is the way PDSE (and HFS) members and directories are serialized. And the reopen just hits the latch, not the ENQ. How do I show ENQ's ? I am afraid I don't have any experience with stuff like this. I also have no idea what a latch is...? TSO RMFMON SENQ D M goes back to menu. Z exits the utility. (And yes, I have performed open-heart-surgery in the OMVS asid by terminating a tcb there via callrtm when absolutely NO logon to uss or access to any new HFS file was possible anymore. That tcb held the needed latch. It was preferable to reIPL a production system during the day.) Interestingly, I have run into the same logon / HFS file access problems twice now, while debugging my remove() code with dbx... Technical support had to intervene both times to get my uss logon to work again. They said it is a latch contention problem. This seems to point to a latch problem, like you said. If only I know what a latch was... Maybe you can explain or point to some doc about latches? Thanks, Etienne -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: John Gilmo re's Mungi ng of Subj ect lines (was Re: H ashin g al gorith m)
john gilmore wrote: The munging comes and the munging goes. Today it is occurring. Yesterday it did not. Did you use hotmail to post yesterday? All the munged posts have the previously reported odd header: Content-Type: text/plain; charset=windows-1256 John Gilmore Ashland, MA 01721-1817 USA _ Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2 -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Munged Sub ject [Calc ul ate Tap e B ytes t o Tr acks? ]?
In article snt113-w6351d9b6b415fb1ce87cbec6...@phx.gbl you wrote: Steve's question is an interesting one. As the culpable party, or at least the source of the first munged title, the only light I can shed on it is that the copy of that post in my sent folder is not munged. It also remains unmunged when I send a copy of it to myself, but that trip is a very short one out to and back from my ISV. I'm guessing the newsservers are getting confused by the odd encoding choice: Content-Type: text/plain; charset=windows-1256 John Gilmore Ashland, MA 01721-1817 USA -- Don Poitras -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best practice for 24-bit storage in assembler called from C/C++
In article 4b8389b7.9030...@gmail.com you wrote: Charles Mills wrote: The fundamental problem I guess is that any solution that keeps a pointer around somewhere in the code is fundamentally not reentrant, unless I can figure out how to utilize pseudo-registers. I've heard the term pseudo-register for years but I have never delved into them. Perhaps now is the time. You're fundamentally not reentrant if you use any kind of global data. That may be name/tokens, control block anchors or WSA. That may not be a problem for you if you only want one instance of the routine. I prefer to design C++ applications to use objects which can handle multiple instantiations of the same class even if I only need one instance. You never know when that requirement may change. The purpose of WSA is to provide reentrancy. Every copy of the program will get it's own WSA initialised when the program starts. No different than in assembler where you do a GETMAIN and use MF=L macros. RELATED: is anyone using void *__malloc24(size_t size);? If you code it then it does not compile; if you code your own declaration then it does not link. At least not in my code. Yes, I included stdlib.h. Obviously, not a big deal to write an assembler GETMAIN routine, but still ... Charles -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best practice for 24-bit storage in assembler called from C/C++
In article 4e2421a41002230531i1d252a29n484a6c323ae9b...@mail.gmail.com you wrote: On Tue, Feb 23, 2010 at 12:07 PM, Don Poitras poit...@pobox.com wrote: In article 4b8389b7.9030...@gmail.com you wrote: Charles Mills wrote: The fundamental problem I guess is that any solution that keeps a pointer around somewhere in the code is fundamentally not reentrant, unless I can figure out how to utilize pseudo-registers. I've heard the term pseudo-register for years but I have never delved into them. Perhaps now is the time. You're fundamentally not reentrant if you use any kind of global data. That may be name/tokens, control block anchors or WSA. That may not be a problem for you if you only want one instance of the routine. I prefer to design C++ applications to use objects which can handle multiple instantiations of the same class even if I only need one instance. You never know when that requirement may change. The purpose of WSA is to provide reentrancy. Every copy of the program will get it's own WSA initialised when the program starts. No different than in assembler where you do a GETMAIN and use MF=L macros. This really depends on how you get access to the program with the WSA. If you load a program once and put the address in commonly retrievable area (vector table, name/token pair, etc.) then WSA does not provide reentrancy. We're back to talking about something other than batch programs. The OP wasn't asking to write a system service, just a job that builds a DCB in assembler. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best practice for 24-bit storage in assembler called from C/C++
I think we're getting a lot of suggestions as if this were some system service. Name/token, CDE lookups and such are fine if you need to bootstrap yourself from some unknown state. The description of this program is just batch. Save the address in an external variable. LE provides macros to allocate and access externs from assembler. See CEEPDDA and CEEPLDA. Read the LE Programming Guide for descriptions. You can even share these areas with your C++ code. Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Charles Mills Sent: Sunday, February 21, 2010 8:00 PM To: IBM-MAIN@bama.ua.edu Subject: Best practice for 24-bit storage in assembler called from C/C++ I'm writing a fairly large MVS batch application in C++. At several points it is necessary to call library type routines that I am writing in assembler. Several of the routines (unfortunately) need to use QSAM macros and so need below-the-line storage. Obviously I could do a GETMAIN or STORAGE OBTAIN LOC=24 on the way in and FREEMAIN or STORAGE RELEASE on the way out. But that's less than optimal for a routine that is called multiple times. (And it would not work at all if the routine had to save state across calls, but fortunately that is not the case, at least for my requirements so far.) I could make the calling C++ responsible for providing a work area obtained with _malloc24(). But I don't like that for aesthetic reasons - violates encapsulation, making the caller responsible for the inner workings of the called function. Is there a better way? Is there some sort of anchor word where a library of called assembler routines could save an address across calls? Is this what CEECAA_TCASRV_USERWORD in CEECAA is for? Does R12 reliably point to the CEECAA on entry? Can I count on CEECAA_TCASRV_USERWORD being initialized to zero? Where is this stuff documented? I don't see much in LE Programming, in LE ILC, or in the C/C++ Programming Guide. SNIP If you KNOW that you will be serialized, then you can either build your DCB info into a REUSE program that you can LOAD. You can then call it to do the I/O that you need done, not get into all the overhead of multiple OPEN/CLOSE, etc. You can then do an INIT call and a Terminate call for the OPEN and CLOSE issues. Otherwise, you can get the storage from your assembler routine, and then have it IDENTIFY that storage so that you can find it again using LOAD, or a run of the CDE chain(s). Just two options you might want to consider. Regards, Steve Thompson -- Opinions expressed by this poster may not reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Best practice for 24-bit storage in assembler called from C/C++
In article 01c601cab431$e5207ff0$af617f...@org you wrote: Thanks, Tony. Yes, the amount of processing varies but is more than atomic, I guess. It does not fit a model of open/get/get/get/close for which a handle is well-suited. There's not much relationship among the routines other than that they're all part of a single larger solution, they're all in assembler, and I wrote them all g. I thought I had a pretty good solution and I just spent a frustrating afternoon coding it -- but I've hit a possibly fatal snag. I had this bright idea of coding a pointer in global storage in the C++ code and doing a __malloc24() into it, and then referencing it with EXTRN from the assembler, but the pre-linker is not resolving it. The fundamental problem I guess is that any solution that keeps a pointer around somewhere in the code is fundamentally not reentrant, unless I can figure out how to utilize pseudo-registers. I've heard the term pseudo-register for years but I have never delved into them. Perhaps now is the time. LE uses the term WSA (Writable Static Area.) It's where reentrant externs and statics live. You get it when you compile your C/C++ program with the RENT option. If you want to use this in assembler, you should use the LE macros rather than trying to use CXD and qcons and such. RELATED: is anyone using void *__malloc24(size_t size);? If you code it then it does not compile; if you code your own declaration then it does not link. At least not in my code. Yes, I included stdlib.h. Obviously, not a big deal to write an assembler GETMAIN routine, but still ... __malloc31 and __malloc24 were intended to be used by LP64 callers. If you really want to use them, I think you'll need to convert your program to 64-bit. If the only use is to hold a DCB, this is overkill. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Tony Harminc Sent: Monday, February 22, 2010 5:54 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Best practice for 24-bit storage in assembler called from C/C++ On 21 February 2010 21:00, Charles Mills charl...@mcn.org wrote: I'm writing a fairly large MVS batch application in C++. At several points it is necessary to call library type routines that I am writing in assembler. Several of the routines (unfortunately) need to use QSAM macros and so need below-the-line storage. Obviously I could do a GETMAIN or STORAGE OBTAIN LOC=24 on the way in and FREEMAIN or STORAGE RELEASE on the way out. But that's less than optimal for a routine that is called multiple times. (And it would not work at all if the routine had to save state across calls, but fortunately that is not the case, at least for my requirements so far.) It sounds as though you're doing a relatively large amount of processing on each call, i.e. you're not just reading a record and return it. So perhaps GETMAIN on the way in, and FREEMAIN upon exit wouldn't be too bad. I could make the calling C++ responsible for providing a work area obtained with _malloc24(). But I don't like that for aesthetic reasons - violates encapsulation, making the caller responsible for the inner workings of the called function. If your library routines are logically related, you could have an init call that returns a handle to the C++ routine, which would be responsible for maintaining it across calls. Then the handle is part of each subsequent call, including the final cleanup one. That sounds like an appropriate level of opacity/encapsulation. If you want to think of all this in terms of objects and constructors/destructors, well fine. The handle is really just the address of your BTL storage block, of course. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IPCS - How to find Load Point
You might be able to just use the IPCS LIST command (of the EP) and scrape the output. It shows the offset from the start of the module. In article 45d79eacefba9b428e3d400e924d36b9030dc...@iwdubcormsg007.sci.local you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Wayne Driscoll Sent: Wednesday, February 10, 2010 4:09 PM To: IBM-MAIN@bama.ua.edu Subject: Re: IPCS - How to find Load Point To find the Load Point of a module, I have used field XTLMSBAD - Address of main Storage Block, offset x'0C' into the XLST structure. I use this in conjunction with XTLMSBLN a 3 byte field at offset 9 that is the length of the main storage block. Note that this block is NOT part of the intended program interface, so changes are possible to this block. SNIPPAGE Thanx. I had looked at that (in storage), and it just didn't seem right to me (because I misread it thanks to the color it showed up in), so I didn't use it. But then when I did the math, sure enough it was the Load Point, and a ? and there I was, the Load Point. Again, thank you. Regards, Steve Thompson -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Re : Extracting STDOUT data from USS
In article dc74548a025aff4a85f46926802a9b230412b...@chsa1035.share.beluni.net you wrote: Gee, you do I/O, you wait ... [snip] Sure. I don't know if there is a CICS service to do I/O to some non-CICS dataset, or if it was simply tolerated. Actually, a wait only affects other transactions in the same CICS region as the will have to wait, too. I remember that in the early releases of OpenEdition / OS/390 UNIX CICS and IMS both stated that they do not allow UNIX services from within transactions because teh waits that could result. No matter whether waits are allowed or tolerated there is big differece between a transaction doing an I/O to some dataset or UNIX file and a transaction doing an I/O to some named pipe. In the later case there is a second *independent* process involved. And this process might run or not when the CICS transacion does its I/O (to the pipe). Long waits may result and this must be acceptable to the transaction's purpose. For a while now (5 years or so), you could code your transaction using OTE (Open Transaction Environment.) If a wait is needed, the transaction waits under a special TCB. http://www.zjournal.com/index.cfm?section=articleaid=767 -- Peter Hunkeler Credit Suisse -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where have the control blocks gone?
Clark Morris wrote: On 5 Jan 2010 09:54:17 -0800, in bit.listserv.ibm-main you wrote: Clark Morris wrote: On 5 Jan 2010 07:17:48 -0800, in bit.listserv.ibm-main you wrote: Mike Myers wrote: Steve: I do know that the formatter in IPCS (TCBEXIT IECDAFMT - at least I think that's the right exit - if not, then it's probably IECIOFMT) will display the DCB as a block of data, but does not format its fields either. Mike Myers IP SUMM FORMAT will display DCB info, here's the one for SYSMDUMP: DATA MANAGEMENT,CONTROL BLOCKS FOR OPEN DATA SETS ***DCB,AT LOCATION 7ADF68 (BSAM) DASD +0 , DCBE 7F424B7C KEYCN 00 FDAD 00 076F0005 02DVTBA EF6026 +10 , KEYLE 00 DEVT 2F TRBAL 184E BUFCB 0001 BUFL DSORG 4000 IOBAD 0050C000 +20 , EODAD 8601 RECFM 98 EXLST 7ADFC4TIOT 048C MACRF 0020 IFLGS 00 DEBA 7B516C +30 , OFLGS 92 BEEA68 OPTCD 00 E00908IOBL 0A SYNA 01CIND BLKSI 6180 +40 , WCPO 30013030 IOBA 0050C070 NCP 04 EOBRA D79658 EOBW 00D79658 DIRCT LRECL 1040 +54 , POINT 0001 The LE forms of SYSUDUMP (may be CEEDUMP, my memory is bad), have some very useful formatting and make at least COBOL debugging much easier. I can't think of anything offhand that you can't get from: IP VERBX LEDATA Isn't that using SYSMDUMP and IPCS? I'm talking about the dumps available to most applications programmers. There's nothing stopping any programmer changing his JCL from: //SYSUDUMP to //SYSMDUMP There is a learning curve, but if looking at dumps is something you do for a living, it's worth the effort. I avoided it for years because I couldn't see the benefit, but now I just groan when somebody hands me a huge SYSUDUMP. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where have the control blocks gone?
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Don Poitras Sent: Wednesday, January 06, 2010 8:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Where have the control blocks gone? SNIPPAGE There's nothing stopping any programmer changing his JCL from: //SYSUDUMP to //SYSMDUMP There is a learning curve, but if looking at dumps is something you do for a living, it's worth the effort. I avoided it for years because I couldn't see the benefit, but now I just groan when somebody hands me a huge SYSUDUMP. SNIP I've been following this thread off and on. There is a caveat to the SYSMDUMP that I think needs to be recognized (and if someone has a way around it, I'm all eyes, ears or whatever). SDUMP[X] knowledgeable programs, or programs with error recovery routines: When you use SYSMDUMP, the last dump written clobbers what went before. That is the gotcha you have to be willing to accept. If the last dump allows you to determine what the root cause is... VBG Use FREE=CLOSE on the SYSMDUMP DD. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where have the control blocks gone? -- Now down in the dumps
Thompson, Steve wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Don Poitras Sent: Wednesday, January 06, 2010 12:10 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Where have the control blocks gone? SNIPPAGE Use FREE=CLOSE on the SYSMDUMP DD. Snip That only works if you are not interested in any other ABEND or dump producing event that occurs. If DISP=MOD would work for SYSMDUMP, I could figure out how to split the dumps by processing the file with REXX or some such. [I have a special case with my stuff -- the things I work on are multi-threaded, multi-tasking and one failure may not be related at all to another.] Let me give you an example: Program DRIVER is running. In a daughter TCB a program is writing to DASD and gets an Sx37. Let's say that 10 seconds later, under a different TCB the program I am interested in (SHUCKS) finally gets the S0C3 I set up. That's the dump I really want to look at. But let's have even more fun. Before I can get to the dump DSN with IEBGENER (which would have to be invoked within this JOBSTEP to deal with the DISP=OLD...), another program under a different TCB ABENDS. I just lost the dump I'm really interested in. In this case, my only choice for this is a SLIP. So the SYSMDUMP just can't handle this level of complexity. Welcome to the world of a developer. Thankfully, I have the ability to issue MVS commands and can set SLIPs when and as I need them. But for the typical programmer/analyst in a production world situation that does get to use IPCS, you don't get to do this. There's the rub. You can have multiple SYSMDUMPs. e.g. //SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUMP,FREE=CLOSE //SYSMDUMP DD DISP=SHR,DSN=SASDTP.SYSMDUM2,FREE=CLOSE and if you just can't stand not getting _every_ dump, code a SYSUDUMP as the last one (without FREE=CLOSE): -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where have the control blocks gone?
Mike Myers wrote: Steve: I do know that the formatter in IPCS (TCBEXIT IECDAFMT - at least I think that's the right exit - if not, then it's probably IECIOFMT) will display the DCB as a block of data, but does not format its fields either. Mike Myers IP SUMM FORMAT will display DCB info, here's the one for SYSMDUMP: DATA MANAGEMENT,CONTROL BLOCKS FOR OPEN DATA SETS ***DCB,AT LOCATION 7ADF68 (BSAM) DASD +0 , DCBE 7F424B7C KEYCN 00 FDAD 00 076F0005 02DVTBA EF6026 +10 , KEYLE 00 DEVT 2F TRBAL 184E BUFCB 0001 BUFL DSORG 4000 IOBAD 0050C000 +20 , EODAD 8601 RECFM 98 EXLST 7ADFC4TIOT 048C MACRF 0020 IFLGS 00 DEBA 7B516C +30 , OFLGS 92 BEEA68 OPTCD 00 E00908IOBL 0A SYNA 01CIND BLKSI 6180 +40 , WCPO 30013030 IOBA 0050C070 NCP 04 EOBRA D79658 EOBW 00D79658 DIRCT LRECL 1040 +54 , POINT 0001 -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Where have the control blocks gone?
Clark Morris wrote: On 5 Jan 2010 07:17:48 -0800, in bit.listserv.ibm-main you wrote: Mike Myers wrote: Steve: I do know that the formatter in IPCS (TCBEXIT IECDAFMT - at least I think that's the right exit - if not, then it's probably IECIOFMT) will display the DCB as a block of data, but does not format its fields either. Mike Myers IP SUMM FORMAT will display DCB info, here's the one for SYSMDUMP: DATA MANAGEMENT,CONTROL BLOCKS FOR OPEN DATA SETS ***DCB,AT LOCATION 7ADF68 (BSAM) DASD +0 , DCBE 7F424B7C KEYCN 00 FDAD 00 076F0005 02DVTBA EF6026 +10 , KEYLE 00 DEVT 2F TRBAL 184E BUFCB 0001 BUFL DSORG 4000 IOBAD 0050C000 +20 , EODAD 8601 RECFM 98 EXLST 7ADFC4TIOT 048C MACRF 0020 IFLGS 00 DEBA 7B516C +30 , OFLGS 92 BEEA68 OPTCD 00 E00908IOBL 0A SYNA 01CIND BLKSI 6180 +40 , WCPO 30013030 IOBA 0050C070 NCP 04 EOBRA D79658 EOBW 00D79658 DIRCT LRECL 1040 +54 , POINT 0001 The LE forms of SYSUDUMP (may be CEEDUMP, my memory is bad), have some very useful formatting and make at least COBOL debugging much easier. I can't think of anything offhand that you can't get from: IP VERBX LEDATA -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: dead zone
In article listserv%201001011105537168.0...@bama.ua.edu you wrote: On Fri, 1 Jan 2010 08:41:53 -0800, Edward Jaffe wrote: The z/OS RSM developers introduced functionality to allow Java to acquire storage within the previously thick bar for performance reasons. I would guess, economy in page and segment tables? I'm still intrigued that the (undocumented) option's name contains the substring 32G. Is 32GiB the size of a particular granule in 64-bit storage management? Or might the 32 refer to a fictitious 32-bit addressing capability? --gil At some release 64-bit LE moved the CAA and other control blocks from starting at 4G to 32G. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Hummingbird screen snapshots
Paul Gilmartin wrote: Users repeatedly send me Hummingbird screen snapshots as JPEGs, claiming it's all they can do. Is there no way to capture a Humminbird screen as text? I'm lazy; I want to be able to copy-and-paste, or search for strings in the screen image. One reason I don't use Hummingbird. Thanks, gil Are we talking about Host Explorer? Yes, cut and paste works the same as every other 3270 emulator I've seen. e.g. --- Foreground Selection Panel Option === 1Assembler 11 *FORTRAN debug 2COBOL 12 Member Parts List 3VS FORTRAN 13 *C/370 5PL/I 14 *REXX/370 6VS PASCAL 15 *ADA/370 7 *Binder/Link editor 16 *AD/Cycle C/370 9SCRIPT/VS 18 ISPDTLC 10 *VS COBOL II debug 19 *OS/390 C/C++ 10A *OS/VS COBOL debug 99 *SAS/C Compiler Products Enter / to select option * No packed data support Source Data Packed -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Newsgroup now frozen. Closing by 12/31/2009
Alexei replied that new fora can be requested by sending a note to dwfo...@us.ibm.com. Including the required info below. While the ibm newsgroups have mostly been silent for many years, I still had them on my list. It's a shame they never got the kind of use that I thought they would. The only one with any real activity that I was watching was the TCP one and I'm guessing that that at least will be missed. --- Hi Don, Below is the form and contact to apply for a new web forum on the dW server: -- Requests for new developerWorks forums should be sent to: dwfo...@us.ibm.com We will respond to the requestor with an e-mail containing the following form to be filled out and returned: Requestor: dW zone (primary, secondary): Forum title: Forum description: Welcome text: Date needed: Beta or GA: Forum administrators Audience: Migration: Public: Requestor: The name of the individual who is sponsoring the forum. Additional contact names can be provided, if necessary. dW zone (primary, secondary): The primary forum index the forum should be listed in. The forum metrics will be reported under this index's metrics. For instance, a discussion forum for WebSphere would be listed in the developerWorks Websphere forum index, and forum metrics would be reported under the developerWorks WebSphere metrics report. A secondary listing can also be included under another forum index, if it is relevant to that audience, but metrics will not be reported under the secondary category. For instance, a forum that was relevant to both WebSphere and Linux audiences could be listed under both, but one of the two must be chosen as the primary index for metrics reporting purposes. Choices are: * AIX/Unix * Information Management * Lotus * Rational * Tivoli * WebSphere * Architecture * Java technology * Linux * Open source * Multicore enablement * SOA and Web services * Web development * XML Non-standard choices which may require customization include: * PartnerWorld Forum title: The official title of the discussion forum. This information will be the title on the user interface of the forum. For software, this is usually the product name. For technologies, this is usually one or more topical keywords that readers would be likely to use when looking for a topical discussion forum with a search engine. Forum description: A short paragraph explaining what topics the forum will address. This paragraph will be the description on the user interface of the forum. Welcome text: The welcome message that should be posted to the discussion forum when it first goes live. Date needed: The proposed date the forum should go live. If this date is to coincide with marketing activities for a product launch, please provide the date of the product launch. Beta or GA: Please specify if the forum is to support a beta product or a general availability level product. Forum administrators: A list of individuals who have been identified to be forum administrator/moderators. Administration access entitles a user to view, create, or remove content as well as edit permissions for other users of the discussion forum. Audience: The audience that the discussion forum is intended to serve. Choices are: * Software developers, architects, product administrators (such as DB2 administrators) and other IT roles who frequent the developerWorks site * Partners/ISVs Migration: Does a pre-existing forum exist elsewhere whose contents should be migrated to the new forum? If so, please provide details. The developerWorks team can provide an XML template of the format that pre-existing forum posts must be provided in for developerWorks to be able to import the material into the new forum. Public: developerWorks discussion forums are public for all users and can be viewed by anyone who visits the site. To post to a public discussion forum, the user must register at developerWorks. Requests for restricted forums must be technically evaluated and sized to determine if developerWorks can meet the requirements or whether the scope of work fits within the developerWorks mission. If special requirements are needed, please provide a description of what is required. A meeting to discuss the additional requirements will be scheduled. Please provide any additional information or requirements about your forum request here: -- Don Poitras wrote: Alexei, I don't see any topics comparable to ibm.software.assemblr or any of the many other mainframe groups. Are they hidden, or is there a plan to add more
Re: Newsgroup now frozen. Closing by 12/31/2009
Alexei, I don't see any topics comparable to ibm.software.assemblr or any of the many other mainframe groups. Are they hidden, or is there a plan to add more fora? Alexei Gabler wrote: This Newsgroup is closing. IBM invites participants of this Newsgroup to join one or more of the IBM developerWorks Web forums and community spaces at http://www.ibm.com/developerworks/forums/index.html. You will find comparable topics there. This Newsgroup will no longer accept new postings and will remain available as Read Only through by 12/31/2009. Questions can be directed to swgwe...@us.ibm.com. Thank you for participating in this Newsgroup. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: How do __you__ read non-DB non-XML files in Java?
I think in the early days everyone just used JNI to call the C routines. Besides JRIO, I also see JZOS: http://www-03.ibm.com/servers/eserver/zseries/software/java/products/jzos/jzossamp.html This was third-party-developed stuff bought by IBM in 2006. Kirk Wolf wrote: John, JRIO has not been enhanced in a very long time. The old IBM record framework originated in VisualAge, and now there are tools to build them in RDz. I'm curious to hear specifically what you find confusing with the JZOS RecordGenerator code. It is significantly simpler and faster than the old record framework, which is why we wrote it.Please compare the code and performance of the two and I'm sure you will agree, but any suggestions that you have for improvment would be appreciated. Kirk Wolf Dovetailed Technologies (and IBM JZOS development) On Tue, Nov 17, 2009 at 7:47 AM, McKown, John john.mck...@healthmarkets.com wrote: Timothy Sipples Ah! it looks like JRIO has been enhanced since last I looked at it. Something called the Record Framework has been added. -- John McKown -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM C header files
des...@verizon.net wrote: sas...@sas.com (Don Poitras) writes: Try: #include sys/types.h If you look inside the EDC4H031 member, you see this as the comment. * sys/types.h header file Note that to get hold of something in sys/ you really should not be defining the location of header files with DD cards. There just aren't enough hints in a concatenation of PDSs. Use the SEARCH/LSEARCH parameters and give up SYSLIB completely. For standard headers? I've never needed to do this. The IBM PROCs seem to be setup correctly. For SAS/C, we have a separate file you need to use that maps odd #includes to member names. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM C header files
David Waldman wrote: On Tue, 20 Oct 2009 08:47:51 -0400, Don Poitras sas...@sas.com wrote: des...@verizon.net wrote: sas...@sas.com (Don Poitras) writes: Try: #include sys/types.h If you look inside the EDC4H031 member, you see this as the comment. * sys/types.h header file Note that to get hold of something in sys/ you really should not be defining the location of header files with DD cards. There just aren't enough hints in a concatenation of PDSs. Use the SEARCH/LSEARCH parameters and give up SYSLIB completely. For standard headers? I've never needed to do this. The IBM PROCs seem to be setup correctly. For SAS/C, we have a separate file you need to use that maps odd #includes to member names. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 You should review the compile listing to see if the SEARCH option is in effect. HTH, Dave Waldman You're right. I do have the default SEARCH. That said, the default works fine for the standard headers. I've never needed to override the default. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM C header files
Try: #include sys/types.h If you look inside the EDC4H031 member, you see this as the comment. * sys/types.h header file TYPES is an alias of EDC4H031. Sometimes it's easier to grep for symbols in the UFS location. /usr/include: pwd /usr/include /usr/include: find . -name '*.h' | xargs grep pthread_t ... ./sys/types.h: } pthread_t; The cannonical location for these things are set in stone from UNIX implementations now decades old. Stevens' TCP books are great references for historical context as well as best practices. Pierre Fichaud wrote: Folks, I've been hired to implement SSL socket calls in an existing z/OS product. The IBM SSL API is in C. I'm changing the TCB structure to have 2 listeners, one TCP/IP and the other SSL. They listen on different ports. I've added a TCB layer and so have had to use the pthread API calls. I've defined a structure with a variable in it defined as : pthread_t *thrd; My thinking was that if I included pthread.h ( as the doc states for any of the pthread API calls) that I would get clean compile. Such is not the case. I get the following message: ERROR CCN3045 @PRF01.SSL.C(NEWL05):324 Undeclared identifier pthread_t. My includes in the C source are as follows: #include time.h #include types.h #include socket.h #include in.h #include pthread.h #include stdio.h #include stdlib.h and my SYSLIB concatenation in the compile JCL is : 11 //SYSLIB DD DISP=SHR,DSN=USERID.H X/SYSLIB DD DSNAME=LIBPRFX..SCEEH.H,DISP=SHR IEFC653I SUBSTITUTION JCL - DSNAME=CEE.SCEEH.H,DISP=SHR 12 //DD DISP=SHR,DSN=ISV.DEV.H X/ DD DSNAME=LIBPRFX..SCEEH.SYS.H,DISP=SHR IEFC653I SUBSTITUTION JCL - DSNAME=CEE.SCEEH.SYS.H,DISP=SHR 13 //DD DISP=SHR,DSN=CEE.SCEEH.H 14 //DD DISP=SHR,DSN=CEE.SCEEH.SYS.H 15 //DD DISP=SHR,DSN=CEE.SCEEH.NET.H 16 //DD DISP=SHR,DSN=CEE.SCEEH.NETINET.H 17 //DD DISP=SHR,DSN=CEE.SCEEH.ARPA.H 18 //DD DISP=SHR,DSN=SYS1.SIEAHDR.H I've shown all the includes but I've got over 15K lines to look at. Nowhere do I find pthread_t defined. pthread_t is actually defined in CEE.SCEEH.SYS.H(EDC4H031). Am I supposed to debug IBM's torturous C header file hierarchy? Another issue is that for another SSL program to compile, I had to include the following define: #define _OE_SOCKETS Otherwise, I had en error with the AF_INET defined value. How is one supposed to figure this out? Also, look at the SYSLIB concatenation. The communications stuff is in 4 header files: SYS.H, NET.H, NETINET.H and ARPA.H. Couldn't they combine all this into 1 nice, neat PDS. Maybe there is another #define that will fix the pthread_t problem? I wonder which variable it is supposed to be? I'm going to hard code the typedef pthread_t in my C source to get around the problem for now. Pierre. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CEEPIPI incorrect recovery processing?
If you change to SYSMDUMP and use the IPCS command IP VERBX LEDATA 'ALL', you may be able to get a traceback and PSW/regs at time of ABEND. Gord Tomlin wrote: Just looking for input as to whether this is working as designed before I report it as a defect... If a program that uses CEEPIPI to call HLL subroutines abends while *not* in any of the HLL subroutines, LE recovery processes the abend and transforms a system abend into a LE user abend. Meanwhile, the associated dump is written to SYSUDUMP rather than CEEDUMP. This situation can be recreated by using the samples ASMPIPI and HLLPIPI from the LE Programming Guide, and adding the abend of your choice (I used EX 0,*) after the label TSUB in ASMPIPI. Instead of seeing a ABENDS0C3 in ASMPIPI, you will see a ABENDU4036-2 associated with CEEPLPKA. The only sign of the original abend is in the system trace table. Needless to say, LE's recovery routines have not made a positive contribution to locating the original problem. One of the requirements for a program that uses CEEPIPI to call LE-conforming HLL routines is that the calling routine *not* be a LE-conforming program, so it seems nonsensical on the surface that LE's recovery routines would try to interpret the abend. The LE Programming Guide says: - init_sub creates a LE environment and sets the environment dormant so that exceptions are percolated out of it. - for call_sub, CEEPIPI activates the LE environment before the called routine is invoked, and after the called routine returns, the environment is dormant. It appears to me that LE is doing an incomplete job of ignoring/percolating abends that occur while outside of the LE environment. Does anyone know anything to the contrary? Thanks! -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507, gord.tom...@actionsoftware.com -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
(fwd) Re: Rutan on Global Warming
-- forwarded message -- Path: reader1.panix.com!panix!newsfeed.stanford.edu!postnews.google.com!26g2000yqk.googlegroups.com!not-for-mail From: Mike Granby mi...@mikeg.net Newsgroups: rec.aviation.piloting Subject: Re: Rutan on Global Warming Date: Tue, 4 Aug 2009 11:20:11 -0700 (PDT) Organization: http://groups.google.com Lines: 4 Message-ID: b2db1cdc-cf7c-4704-989f-a693681ad...@26g2000yqk.googlegroups.com References: f7495f98-f2f5-46ff-a1b6-ec80221ad...@k6g2000yqn.googlegroups.com j0ldm.28040$8b7.17...@newsfe20.iad sqqdnfwxzd1ruurxnz2dnuvz_u6dn...@supernews.com NNTP-Posting-Host: 74.94.10.13 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: posting.google.com 1249410011 11179 127.0.0.1 (4 Aug 2009 18:20:11 GMT) X-Complaints-To: groups-ab...@google.com NNTP-Posting-Date: Tue, 4 Aug 2009 18:20:11 + (UTC) Complaints-To: groups-ab...@google.com Injection-Info: 26g2000yqk.googlegroups.com; posting-host=74.94.10.13; posting-account=IFZaFwoAAABrQznEVJHxnnP4gZwCvPeR User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; MS-RTC LM 8),gzip(gfe),gzip(gfe) Xref: panix rec.aviation.piloting:629666 Slides here, but no audio, which was of course the best bit... http://www.slideshare.net/QuestSystems/agw-analysisrutanv5-read-only -- end of forwarded message -- -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: (fwd) Re: Rutan on Global Warming
Sorry, I meant to send that to a pilot friend of mine, not ibm-main. Please don't let this start a GW thread -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Telnet Unix System Services
While I finally bit the bullet and learned (somewhat) how to use vi, I think using it as the command editor is overkill. The emacs keys for recalling commands and moving forward and back on the line are much more amenable to key bindings. I do: set -o emacs and set up arrow to CTRL-p, down arrow to CTRL-n, left arrow to CTRL-b, right arrow to CTRL-f If delete or backspace aren't working, CTRL-d will do delete. Of course, just using the CTRL combinations works too and if you find yourself at a prompt, it doesn't hurt to try them out. :) Mark Pace wrote: in /etc/profile I added set -o vi and then I can do esc k to recall previous commands. Now if I can figure out how to change the keyboard in PuTTY to send an esck for the up arrow. On Thu, Jul 23, 2009 at 7:03 AM, Klein, Kenneth kenneth.kl...@kyfb.comwrote: And when you find that Mark, please post it. I have been looking for that for weeks. Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville kenneth.kl...@kyfb.com 502-495-5000 x7011 -- Mark Pace Mainline Information Systems 1700 Summit Lake Drive Tallahassee, FL. 32317 -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Telnet Unix System Services
You can do up arrow command recall using /bin/sh. Make sure you are using emacs rather than vi as your command entry editor and set the up-arrow key to CTRL-p, down arrow to CTRL-n. In OS/X, you need to set that in the Settings tab of Terminal | Preferences. In article a6b9336cdb62bb46b9f8708e686a7ea003eddc1...@nrhmms8p02.uicnrh.dom you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Mark Post Sent: Wednesday, July 22, 2009 2:59 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Telnet Unix System Services On 7/22/2009 at 3:41 PM, McKown, John jmck...@healthmarkets.com wrote: -snip- I am not 100% sure, but I think those are differences in /bin/sh on z/OS UNIX, which is based on the Korn Shell, and the use of BASH as the default shell on Linux. I would tend to agree. It's one of the reasons I compiled and installed bash on USS many years ago. Mark Post Ah! So you're running BASH on z/OS UNIX and still getting the differences? I have Bash 2.03 on my z/OS 1.10 system. The up arrow key works fine on my telnet emulator. I run Hummingbird under Windows XP. The tab also does file completion. I got it from: http://www-03.ibm.com/servers/eserver/zseries/zos/unix/bpxa1ty1.html I also used the telnet client that is on my Linux/Intel box. It also works, but not quite properly. It works but does not display properly. I.e. I type in ls -l x4 and get a good display. I press up arrow and ^[[A displays. I then press enter and get the response from the previous command. IOW - the up arrow using this client does not redisplay the actual command line that it fetched into the buffer. Most weird. -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Language Environment runtime options and system dumps
Ramiro Camposagrado wrote: On Fri, 12 Jun 2009 15:23:39 +0100, Jim McAlpine jim.mcalp...@gmail.com wrote: Is there any combination of LE runtime options that will give a system dump of the original abend and an LE message. Jim McAlpine Using TRAP(OFF,NOSPIE) should give you the original ABEND. I;m not so sure about the LE messages though. If you turn off the LE ESTAE, then you're not going to get the happy LE traceback and messages. But in most cases, the dump still contains the original abend info. Just don't use IP SUMM FORMAT to get the info. Instead, use IP VERBX LEDATA 'CM' (without the double quotes.) This gives you PSW and regs at the time of original ABEND. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: EXEC Above the Bar (Was Large Page Support)
In article listserv%200906052142508773.0...@bama.ua.edu you wrote: On Fri, 5 Jun 2009 16:18:07 -0500, Rick Fochtman wrote: In z/OS V1.11, support is added for data tables contained in load modules and program objects to be placed above 2 GB. A new ADDR64 --unsnip-- constraint relief. I'll have to rethink the addressing scheme for moving around within the tables, since I doubt that anything would actually go through relocation. At least I have the most important element: TIME! Perhaps an IBM employee can clarify this. Does HLASM provide support for 64-bit ADCONs (or will it in 1.11)? Even prior to HLASM support will Binder provide support for 64-bit RLDs? I'm not sure about RLD, but DC AD() has been around since I believe the first HLASM to support 64-bit. If I need to set a register to some label, it's easier to do LG Rx,=AD(myroutine) than fiddle with clearing the high half and has the advantage of doing what is needed if the routine ever does move above the bar. By experiment, I discover that HLASM won't let me create a CSECT 16MiB. It won't let me create a program with multiple CSECTs totalling 16 MiB(?!) Sigh. It will let me assemble multiple programs totalling 16 MiB in a single job step. So you also may need ORDER commands to control the load sequence. -- gil -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDSE Load Module Format?
Paul Gilmartin wrote: On Wed, 15 Apr 2009 12:53:11 -0400, Tony Harminc wrote: AFAIK, all C compilers from ISVs require a prelinker step which, in turn, is highly hostile to processing performed by SMP/E. Certainly it is, but I'm not sure why compilers need such a step. Can you give an example? A reentrant and refreshable program needs to obtain writeable storage and may need to move an initializing prototype into that storage. C allows the initializing prototype to be defined in a translation unit other than the one containing the main entry point, and expects that initialization to have been performed when the main entry point gets control. A preprocessor is needed to move the initializing code (GETMAIN; MVCL) from that other translation unit to the one containing the main entry point. I suspect (and Dave Rivers seems to confirm) that there are undocumented facilities in Binder to facilitate this; in effect a built-in preprocessor. -- gil I guess you're saying that you need to use the binder to create Program Objects. I think it would be difficult for an ISV to create their own. I'm not sure why they would want to. There's certainly enough documented info to create objects that can be directly read by the binder without pre-linking. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: PDSE Load Module Format?
Paul Gilmartin wrote: On Thu, 16 Apr 2009 09:36:25 -0400, Don Poitras sas...@sas.com wrote: I guess you're saying that you need to use the binder to create Program Objects. I think it would be difficult for an ISV to create their own. I'm not sure why they would want to. There's certainly enough documented info to create objects that can be directly read by the binder without pre-linking. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 Ahem... Guess what ISV's C compiler requires a pre-linker. -- gil We never sold a compiler that produced GOFF output. Doesn't mean it can't (or hasn't) been done. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: New TOD
In article p06240801c60847976...@[192.168.1.11] you wrote: At 18:32 + on 04/12/2009, john gilmore wrote about Re: New TOD: In particular, as I noted on another occasion, calendrical arihmetic is rendered trivial when dates are stored as the signed number of elapsed days from some epoch origin, of which the two reasonable ones are: or 2) midnight 31 December , which is the epoch origin of the Gregorian calendar, The Gregorian Calendar did not start sometime from 1582 (for the Roman Church) to 1752 (the UK and the US [American Colonies at that point]) through 1926 (Turkey) so you have to state what country you are talking about. The skipping of anywhere from 10 to 13 days in the switch from the Julian Calendar also screws up dates (for example Washington's Birthday is NOT celebrated on his actual birthday since he was born on a Julian (OS/Old Style) date/year. The switchover to Gregorian is only needed when trying to figure out some historical event. Both Julian and Gregorian Calendars come in proleptic versions though which just roll both directions in time forever. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Display true hex as EBCDIC characters?
sumit arora wrote: but will not UNPK dump while unpacking '017B' as it will look for 'c' , 'd' , 'f' e' as sign bit not 'B' UNPK just moves bits around, he doesn't validate the source field. Note that in Tony's example, both field lengths are one byte longer than the real input and output fields. This is so that the last byte reversal that UNPK does is thrown away. You have to be sure that your input has that last byte in readable storage even though you won't be using the output. i.e. x'17b' becomes x'F1F7FB' and whatever the byte after it is gets revesed. One nit: MVC OUTAREA(8),UNPACK10+1 should be: MVC OUTAREA(8),UNPACK10 It's the last byte that gets discarded, not the first. --- On Mon, 2/2/09, Tony Thigpen t...@vse2pdf.com wrote: From: Tony Thigpen t...@vse2pdf.com Subject: Re: Display true hex as EBCDIC characters? To: assembler-l...@listserv.uga.edu Date: Monday, 2 February, 2009, 6:34 AM Sorry, forgot the MVC: R1 points to 4 byte hex field. UNPK UNPACK10,0(5,R1)UNPACK HEX CODES TRUNPACK10(9),TRTAB CONVERT TO PRINTABLE HEX-VALUE MVC OUTAREA(8),UNPACK10+1 UNPACK10 DSCL10 TRTABEQU *-240 ENTRY POINT FOR TRANSLATE TABLE DCX'F0F1F2F3F4F5F6F7F8F9C1C2C3C4C5C6' TRANSLATE TABLE Tony Thigpen -Original Message - From: Tony Thigpen Sent: 02/01/2009 07:42 PM R1 points to 4 byte hex field. UNPK UNPACK10,0(5,R1)UNPACK HEX CODES TRUNPACK10(9),TRTAB CONVERT TO PRINTABLE HEX-VALUE UNPACK10 DSCL10 TRTABEQU *-240 ENTRY POINT FOR TRANSLATE TABLE DC X'F0F1F2F3F4F5F6F7F8F9C1C2C3C4C5C6' TRANSLATE TABLE Tony Thigpen -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: vsnprintf(); off by 1!?
Paul Gilmartin wrote: On Mon, 12 Jan 2009 22:31:50 -0800, Henry Willard wrote: memcpy( ap, xp, sizeof( va_list ) ); is not legal C. Either use the c99 va_copy (va_copy(ap,xp)) created for this purpose or define _VARARG_EXT before including stdarg.h. Up until c99 there was no defined way to do what you were trying to do although your method as well as direct assignment worked on many but not all systems. Thanks for educating me. Hmmm... #define _VARARG_EXT_ leads to: Trying vsnprintf(); CEE3204S The system detected a protection exception (System Completion Code=0C4). From entry point f2 at compile unit offset +01A4 at entry offset +01A4 at address 448CCADC. [1] + Done(139) gmake varg amp; ./varg 67109204 Segmentation violation ./varg ... a step backward. If vsnprintf() is incompatible with _VARARG_EXT_, it would be a courtesy to the programmer to manifest this at compile time, possibly by using char** instead of va_list to expose the incompatibility. I see that va_copy() is defined as: #define va_copy(dest, src) ((dest) = (src)) ... simple enough. But our systems programmer hasn't configured the c99 environment. If I undefine and redefine va_start, adding a call to va_arg at the end, it works OK. But my real goal is to get it working in enhanced ASCII mode. And that fails with: c89 -I.. -D_ALL_SOURCE -Wa,ASA,RENT -Wl,xplink,EDIT=NO -Wc,dll,ascii -o varg ../source/varg.c /usr/lib/Xaw.x /usr/lib/SM.x /usr/lib/ICE.x /usr/lib/X11.x -lcurses -sh 0 + ./varg -sh 0 + 2 1 -sh 0 + iconv -f ISO8859-1 -t IBM-1047 CEE3204S The system detected a protection exception (System Completion Code=0C4). From entry point f2 at compile unit offset +0060 at entry offset +0060 at address 448F0190. Format: %s -- %s Thanks, gil I believe you also need: #define _ISOC99_SOURCE as shown in the doc. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:sas...@sas.com (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sending snmp traps from z/OS
In article [EMAIL PROTECTED] you wrote: On Tue, 25 Nov 2008 09:23:10 -0500, Don Poitras [EMAIL PROTECTED] wrote: ... If you're willing to write some code, you can use DPI to issue the traps. See: http://publibz.boulder.ibm.com/cgi- bin/bookmgr_OS390/BOOKS/ezap4002/5.0 ... I hadn't looked at DPI for several years so I had to refesh my memory. I could have easily overlooked something, but as near as I can tell, DPI is primarily for communication between agent and subagent. A subagent can use DPI to generate a trap. Isn't that what the OP was asking how to do? Yes, this requires the standard MVS SNMP agent to be up and running. However, (if I understand the term manager) it sounds like this really should be a SNMP manager function. Sort of a manager to manager process (which may be outside of official SNMP use.) I see in a z/OS 1.9 manual that there is an SNMP Manager API available in 1.9. I'm stuck on 1.8 so I can't check this out, but I saw a What's new doc on the web that says: z/OS Communications Server also provides an extension of the SNMP Manager API, the SNMP Notification API, which leverages the functionality of the SNMP Manager API to send notifications to SNMP agents and/or SNMP Notification Receivers. Available notifications include Informs and both Version 1 and Version 2 Traps. I think this API is really the way to go if you have 1.9 or later. The OP wanted to send traps, not receive them. I've never looked into Informs, but I gather they are sort of guaranteed delivery traps. Pat O'Keefe -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [EMAIL PROTECTED] (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: sending snmp traps from z/OS
In article [EMAIL PROTECTED] you wrote: On Thu, 20 Nov 2008 14:09:47 -0600, Henrique Seganfredo [EMAIL PROTECTED] wrote: Hello folks, ... Surprisingly, the command line tool (/bin/snmp) that interfaces with the snmp agent task only gives me the opportunity to RECEIVE TRAPS and not to SEND THEM. ... It looks like a reply I gave over the weekend never made it. I'll try again. Sorry if this is a duplicate. (I'll be even sorrier if it disagrees with my previous attempt.) I'm surprised to find that, too, but it appears to be the case. If you have NetView there are 2 techniques you can useto generate SNMP traps. snip If you're willing to write some code, you can use DPI to issue the traps. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ezap4002/5.0 -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [EMAIL PROTECTED] (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
(fwd) Re: Run-time Environments from SHOWZOS
On Thu, 20 Nov 2008 13:33:13 -0800, John Norgauer [EMAIL PROTECTED] wrote: When I run SHOWZOS on Z/os 1.9 I see the following for sas/c: n/a On my old z/OS 1.7 system, I see the following for sas/c: SAS/C -LNKLST- ISP.SISPSASC I have no dataset for ISP.SISPSASC on my z/OS 1.9 system. Is this correct? Thanks John Norgauer Yes. IBM no longer distributes the SAS C run time. IBM now eats their own dog food by using the LE C run time. -- John If you do need the library though, contact Sas technical support and ask for the version you need. We'll send it free of charge. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [EMAIL PROTECTED] (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Prevent IEW2456E error with cmd in SYSLIN
Gilbert Saint-Flour wrote: Hello! The job below gets an IEW2456E error (and RC=8) because the PROG222 program contains EXTRN XX which is not available. The XX module is sometimes needed, but not in this case. It would be better if PROG222 defined XX with WXTRN instead of EXTRN, but this is not an option because it's not an assembler module ! I could add the NOCALL option to the PARM, but I have a good reason to NOT do that. So my question is this: is there a command I can code in SYSLIN to avoid getting the IEW2456E error and RC=8 ? I looked in the doc but wasn't able to find it, although I vaguely remember that I found one in the past. Thank you for your help. I don't know of one in SYSLIN, but you can code LET as a parm and the program will be marked executable. I don't see how NOCALL will help here as if the symbol can't be resolved through direct includes, stopping it from autoincluding doesn't make matters better. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ //LKED EXEC PGM=IEWL,PARM=(LIST,MAP,RENT) //SYSPRINT DD SYSOUT=* //SYSLIB DD DSN=IBMUSER.LOAD222,DISP=SHR //SYSLMOD DD DSN=IBMUSER.LOAD,DISP=SHR //SYSLIN DD * INCLUDE SYSLIB(PROG222) NAME PROG222(R) /* -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IPCS NAMETOKN Command
It's been a while since I wrote this, but sometimes an example will explain
more than pages of doc. Just a snippet of an exec I use to analyze Sas
dumps:
000246if validtok = 1 then
000247do
000248 subtokx = 'SUBT'
000249 nametokn tcbptr str(tcb) asid(casidd),
000250name((SASTK THREAD)) nolist rexx(token(subtokx))
000251 subtokc = left(c2x(subtokx),8)
000252 if subtokc 'E2E4C2E3' then /* if not 'SUBT' */
000253 do
000254eyep = eval(HexAdd(subtokc,4))
000255/* I do binary here, due to the odd decision to have eval of
000256 character uppercase the result... */
000257eyeb = eval(eyep,32,b)
000258/* flip it back to character */
000259eye = x2c(eyeb)
000260/* truncate trailing nulls */
000261x = pos('00'x, eye)
000262if x = 0 then
000263 x = 32
000264else
000265 x = x - 1
000266eye = substr(eye, 1, x)
000267 end
000268end
000269GEN$ = splat'TCB: 'right(tcbptr,6)' O='right(otc,6)' CMP='cmpf,
000270 'OPSW='opsw1' 'opsw2' EP='left(ep,8)' 'eye
000271call Put
000564 /* return value at specified address */
000565 /**/
000566 /* Parms: 1 - address */
000567 /*2 - length of value to return (4 is default)*/
000568 /*3 - type of value to return ('C' or 'X') ('X' is default) */
000569 /**/
000570 eval: procedure expose aq
000571
000572 if arg(2) = ''
000573then len = 4
000574else len = arg(2)
000575
000576 if arg(3) = ''
000577then type = x
000578else type = arg(3)
000579
000580 evaluate arg(1). aq le(len) type rexx(storage(result))
000581
000582 if rc 0
000583 then return -1
000584 else
000585 return result
In article [EMAIL PROTECTED] you wrote:
Bob, thanks, but I guess I need to dig deeper into the REXX manuals. I
haven't done a ton of REXX work in years, except for some IPCS stuff,
and this one has me stumped. The token contains an address and other
data. I was expecting that REXX(TOKEN(VAR)) would behave similar to
REXX(STORAGE(VAR)) does in the evaluate and set the variable to an
external format, since it doesn't, I need to find the REXX function to
get it into this format.
Wayne Driscoll
Product Developer
JME Software LLC
NOTE: All opinions are strictly my own.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Robert Wright
Sent: Friday, February 01, 2008 8:26 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: IPCS NAMETOKN Command
Wayne Driscoll wrote:
Once again I find myself writing IPCS formatting execs. My
application
makes use of name/token pairs, and I am attempting to track down the
contents. I know how to dig the contents out myself, but I would
prefer
to use the supported method, but I am having a problem. I issue the
command
Nametokn ASCBnnn nolist rexx(token(tokeval))
And if tokeval changes from the pre-seed that I use, I know I have
token
I am looking for. All good. However, the contents of the rexx
variable
is unformatted data, so how do I utilize the data? If I specify LIST
it
is able to format the data, but I want to use the data for later
processing (basically I would like to perform in a program actions
similar to the actions done manually in the second example of the
NAMETOKN command in the IPCS Commands manual.
REXX provides you the means to break TOKEVAL apart into the bytes that
have independent meaning to your application. If some of that data
yields a storage address or length, REXX can convert the binary value to
an EBCDIC one that can be substituted into an appropriate IPCS
subcommand to access the addressed data and the length of the instance
referenced. If the piece is truly EBCDIC and printable in the 1st
place, no conversion is needed.
Bob Wright - MVS Service Aids
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
[EMAIL PROTECTED] (919) 531-5637Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ISPF Action Bar Menus
You can just do this for yourself. I make a copy of the panels and process them to get rid of the action bar. I find it annoying even with 43 lines. Eric Bielefeld wrote: Thanks John. I forwarded that to my Aviva email address. I doubt if I would even ask them to do that, as I doubt that there are that many people who care there about the presence of absense of the action bar. I have to forward all the good suggestions to my email address at Aviva, because I'm back home in Milwaukee for the holidays, and won't go back to work until Thursday the 3rd. Its great being home, but as a contractor I don't get paid too much being home! Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: McKown, John [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Wednesday, December 26, 2007 9:13 AM Subject: Re: ISPF Action Bar Menus -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Wednesday, December 26, 2007 9:09 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ISPF Action Bar Menus I could swear that when I was at PH Mining running z/OS 1.2, that there was an option to delete the whole action bar from all menus. My memory being what it is though, I may be wrong! At Aviva, we are currently running z/OS 1.4, and migrating to 1.7 early next year. Perhaps? http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ISPZPC10/2.1. 3 -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Another Branch Trace question
Hardee, Charles H wrote: In reference to the level of z/OS, I can find that in a dump when using IPCS. Can I also find the hardware level within a dump using IPCS? Thanks, Chuck The PCCA contains the PCCACPID which has serial and model numbers. The z9 is 2094 and 2096. We recently got one of these so I can finally use the BEAR. Here are some notes on I have on locating the BEAR, gleaned from Share or other sources: Where are BEAR contents saved: When a Program interrupt occurs, the contents of BEAR are stored in PSA+x'110' (FLCEBEA) in low core When a Program check occurs, RTM will copy into SDWABEA (SDWARC4 +150), RTM2BEA (RTM2WA +6D0) ST FAILDATA or VERBX LOGDATA will provide contents of BEAR If SDWARC4 is available (above-the-line SDWA only) I do: IP SUMM FORMAT then F rtm2wa then F 'bea..' +06D0 BEA.. 199FACDC +06D8 PSW1. 0785 8000 199FA66E So the last successful branch in this program was at address 199FACDC. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Ways to update PS files?
In article [EMAIL PROTECTED] you wrote: There are straightforward ways to update [necessarily] DASD-resident PS datasets in assembly language using the NOTE and POINT macros (q.v.), but I am not aware that any statement-level procedural language supports these operations, and Enterprise COBOL certainly does not. (An LE-compliant pair of COBOL-callable HLASM subroutines would of course be easy to write.) John Gilmore Ashland, MA 01721-1817 USA Both SAS/C and IBM C can update PS files if the recfm is FBS. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [EMAIL PROTECTED] (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: ways to update PS files?
In article [EMAIL PROTECTED] you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of john gilmore Sent: Monday, August 20, 2007 8:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: ways to update PS files? As usual, we have a lot of people posting comments about things they know little about. NOTE and POINT, as reference to the current z/OS DFSMS Macro Instructions for Data Sets manual will confirm, are usable only with BSAM and BPAM. Was someone insisting that QSAM be used? Much depends upon what kinds of update processing are required, in particular upon whether non-sequential processing is required. John Gilmore I think the simpliest answer to this question is just plain NO. Granted, that technically it can be done, it is not something that your average application programmer would want to try. If something needs to be updated ad hoc, then I'd suggest AMASPZAP. If something needs to be updated with any regularity, then I'd strongly suggest that an ESDS would be simplier to do than a PS file. The only minus is that an ESDS cannot be read as easily by an application as a PS file. Too bad IBM didn't make a PS compatability interface so that an ESDS could be read/written via a QSAM or BSAM DCB in addition to a DCB. I think that this is possible in z/VSE's version of an ESDS (but I could easily be wrong). If you can specify the RECFM of the dataset, then PS files are easy to update and very fast. C programmers are used to using fseek, ftell and so forth. I'm not sure if they consider themselves average, but I doubt they look on themselves as rocket scientists. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive [EMAIL PROTECTED] (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: FW: Jim Keohane
Although I didn't have a close relationship with Jim, I worked with him on many SAS/C issues over the years and I don't think I've ever seen a customer that was easier to get along with. Besides having great technical skills, he made extra effort to understand issues that we had as an ISV. I looked in our database and the earliest track I see was from 1994. On one hand, I suppose that it would be better if he didn't need to use our tech support so much (for issues that turned out to be errors on our part), but you knew when you got a problem from Jim, it would at least turn out to be interesting. :) He will be missed. Richards.Bob wrote: For those that knew Jim. Bob Richards -Original Message- From: MQSeries List [mailto:[EMAIL PROTECTED] Behalf Of Jim Keohane Sent: Friday, May 25, 2007 9:45 AM To: [EMAIL PROTECTED] Subject: Re: Unsubscribe Help Sir This is Jim's wife and I am sorry to say Jim passed away last Thurs. I am trying to clean up the business and all his associations if you could assist in removing him from your lists it would be appreciated. I am not a computer genius that was Jim's area. Thanks Rae Keohane Jim Keohane Multi-Platforms, Inc. Levittown, NY -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: META: IBM-Main via Listserv vs. Usenet
ditto Howard Brazee wrote: Top posting because it appears that this post was an example of one sent directly to Usenet - where I would expect Darren to miss it. On Wed, 23 May 2007 13:04:42 -0400, Arthur T. [EMAIL PROTECTED] wrote: In one day I saw at least two interesting posts which many people missed. These were sent directly to the Newsgroup. All posts sent to the Listserv are mirrored to this Usenet group. Posts made directly to Usenet are *not* seen by those who read the group via e-mail. I don't know what the proportion is, but a lot of shops don't have news feeds. Darren (if you see this), would it be desirable and reasonably easy to set up a monthly post (Usenet only if possible) to remind people of this and to let newcomers know? N.B. You can tell posts sent directly to Usenet in a couple of ways. The most obvious is that they lack the sig added by the mirroring program which tells how to join the Listserv. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: calling ISPLINK from COBOL
Steve Comstock wrote:
Jim McAlpine wrote:
I'm trying to convert the following pseudo code to run under COBOL -
DCL TCCSID CHAR(5); /* TERMINAL CCSID */
CALL ISPLINK('VDEFINE','ZTERMCID',TCCSID,'CHAR',
LENGTH(TCCSID));
CALL ISPLINK('VGET ','ZTERMCID','SHARED ');
and I've come up with -
WORKING-STORAGE SECTION.
01 TCCSID PIC X(5).
01 LCCSID PIC S9(8) VALUE 5.
01 VDEFINE PIC X(8) VALUE 'VDEFINE '.
01 ZTERMCID PIC X(8) VALUE 'ZTERMCID'.
01 CHAR PIC X(4) VALUE 'CHAR'.
01 VGET PIC X(8) VALUE 'VGET'.
01 SHARED PIC X(8) VALUE 'SHARED '.
PROCEDURE DIVISION.
CALL 'ISPLINK' USING
VDEFINE ZTERMCID TCCSID CHAR LCCSID.
DISPLAY RETURN-CODE UPON SYSOUT.
CALL 'ISPLINK' USING
VGET ZTERMCID SHARED.
DISPLAY RETURN-CODE UPON SYSOUT.
DISPLAY TCCSID UPON SYSOUT
GOBACK.
Items have to be in a specified order; for VDEFINE its:
VDEFINE - the verb; you're OK there
name-list - you have ZTERMCID, looks OK
variable - you have TCCSID, 5 byte area where value is to
be placed; looks OK
format - you have CHAR; OK
length - you have LCCSID; this must be a fullword
binary integer; you have 8 bytes of
display;
Try chaning LCCSID to be defined as:
LCCSID pic s9(8) binary value 5.
I find that using the ISPF 'MODEL' command is useful when writing ISPF
programs. Make sure you're editting a PDS with a name such as
MYNAME.TEST.COBOL and then issue 'MODEL WORKSTORE' and the 'a' line
command where you would like the working storage fields entered. Then go
down to the procedure division and to a 'MODEL VDEFINE' for a sample and
=NOTE= comments. Same for the other ISPF services. Do 'MODEL' by itself
to bring up a list of all the services.
but I'm getting rc=20 - severe error from both calls to ISPLINK. It's 20
years since I've done any of this stuff and I've been looking at it all
afternoon without success. Can someone put me out of my Friday afternoon
misery please. Is it time to go home yet.
Hard to say: what time zone are you in?
Kind regards,
-Steve Comstock
The Trainer's Friend, Inc.
303-393-8716
http://www.trainersfriend.com
--
Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive
mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: time() in z/OS XL C with LP64 (AMODE 64) -- bug?
Michel,
Odd. Yes, I'm running IBM C. Also 1.8. You should probably open
an ETR. Perhaps your installation is in error.
Hi Don,
As I told in my first posting:
In batch AMODE 31, the following program works fine:
#include time.h/* for date and time functions */
#include stdio.h /* for printf()*/
int main(void)
{
time_t ctime;
struct tm *ptr_to_struct;
ctime = 0;/* retrieve the UNIX epoch*/
ptr_to_struct = gmtime(ctime);
printf(\(1) %s\, asctime(ptr_to_struct));
ctime = time(NULL); /* retrieve the current calendar time */
ptr_to_struct = localtime(ctime);
printf(\(2) %s\, asctime(ptr_to_struct));
return 0;
}
In batch AMODE 31, printf() displays:
--
(1) Thu Jan 1 00:00:00 1970
(2) Mon May 7 14:38:10 2007
(O.K. because asktime() returns a string which includes NL)
In batch AMODE 64, the result is:
--
(1) Thu Jan 1 00:00:00 1970
followed by:
IEF450I ARCIS1X GO STEP1 - ABEND=S000 U4087 REASON=0007
i.e. calling gmtime() is successful but the call of time() fails.
Since you compiled and executed your program in USS, I now performed the
following tests:
In UNIX AMODE 31:
--
IBMUSER:/u/arcis: c99 -o timepgm time.c
IBMUSER:/u/arcis: timepgm
(1) Thu Jan 1 00:00:00 1970
(2) Mon May 7 07:49:44 2007
IBMUSER:/u/arcis:
(O.K.)
BUT in UNIX AMODE 64:
--
IBMUSER:/u/arcis: c99 -Wc,LP64 -Wl,LP64 -o timepgm time.c
IBMUSER:/u/arcis: timepgm
83951656 Killed ./timepgm
IBMUSER:/u/arcis:
i.e. even worse than in batch!
There is no single printf() output!
Just to be sure, I added #define __Posix1a in time.c, but the result is the
same:
IBMUSER:/u/arcis: oedit time.c
IBMUSER:/u/arcis: c99 -Wc,LP64 -Wl,LP64 -o timepgm time.c
IBMUSER:/u/arcis: timepgm
67174442 Killed ./timepgm
IBMUSER:/u/arcis:
In summary:
- in batch AMODE 64, only time() fails;
- in USS AMODE 64, the entire program fails.
TIA for additional comments/suggestions.
BTW, just to be sure: you made your test using IBM's z/OS XL C, or did you
use SAS/C?
Regards,
Michel Castelein
--
Michel Castelein - Arcis Services
MVS-OS/390-z/OS system engineer instructor
arcis[at]advalvas[dot]be
http://www.geocities.com/michelcastelein/
--
Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive
mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: time() in z/OS XL C with LP64 (AMODE 64) -- bug?
In article [EMAIL PROTECTED] you wrote:
Using the C compiler of z/OS XL C/C++ V1.8:
In AMODE 31, calling time() to retieve the current calendar time works fine.
However, when compiling with the LP64 option, the compilation and binding
are OK, but the program execution results in an ABEND U4087 with reason code
7, while running LE-module CELQLIB.
ABEND U4087 indicates that an error during error processing (i.e. a
recursive error) was detected.
I wonder if someone else experienced the same problem.
Is it a (documented) bug?
TIA for the feedback.
Works for me:
/u/sasdtp: cat time.c
#define __Posix1a
#include stdlib.h
#include string.h
#include stdio.h
#include time.h
int main()
{
time_t theTime;
struct tm *lcltime;
char msg_str[80];
theTime = time(NULL);
lcltime = localtime(theTime);
strftime(msg_str, 80, Local time is %m.%d.%Y %H:%M:%S,lcltime);
printf(%.80s\n, msg_str);
return 0;
}
/u/sasdtp: c89 -Wc,LP64 -Wl,LP64 -o time time.c
/u/sasdtp: ./time
Local time is 05.06.2007 17:35:33
Michel Castelein
--
Michel Castelein - Arcis Services
MVS-OS/390-z/OS system engineer instructor
arcis[at]advalvas[dot]be
http://www.geocities.com/michelcastelein/
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
[EMAIL PROTECTED] (919) 531-5637Cary, NC 27513
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DST Again-7 April Boomerang....
Dave Reinken wrote: I would agree that the date in the article is bogus. The boomerang should happen on Sunday, April 1, NOT Saturday, April 7. Cisco would agree, for what it is worth. http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_field_notice09186a00807e02b1.shtml or http://tinyurl.com/3xx43u The article is also internally inconsistant in that it says Daylight savings time (DST) began three weeks early this year, on March 11, 2007, yet also gives the dreaded bounce as 3 weeks and 6 days later. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: DST Again-7 April Boomerang....
[EMAIL PROTECTED] wrote: In a message dated 3/30/2007 11:58:00 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: No, it's always been 1st Sunday in April. Maybe you're thinking Saturday night, at 2 AM, which is really Sunday No, they just did a piece on Headline News. 1st Sunday in April, last Saturday in Oct. the link is just WRONG. Last Sunday in Oct. The changes are always on a Sunday. -- Don Poitras - zSeries R D - SAS Institute Inc. - SAS Campus Drive mailto:[EMAIL PROTECTED] (919)531-5637 Fax:677- Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
