Re: Assembler - convrssion of Epoch (Unix) time to printable
Arye Shemer wrote: Real good stuff, although I hoped for some pure and natural Assembler macro or calling routine solution. If you just want Assembler code to perform the basic arithmetic of converting a z/OS UNIX file timestamp to a displayable date and time, you can look at the source code of the REVIEW command from CBT file 134. Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on adding an SVC routine dynamically to a running system
Dave Day wrote: The SVC in question has but one purpose. To generate a system trace table entry. The code within the SVC clears r15, and then branches r14. Nothing more. Then why not use SVC 50 (x'32')? Cheers, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: TSO SCREENSIZE
Juergen Keller wrote: I wonder what the TERMINAL-command is for. The TERMINAL SCRSIZE setting controls how TSO line-mode terminal housekeeping is performed. Fullscreen applications are free to use an available screen size different from the one used by line-mode TSO. Of course, many fullscreen apps use GTSIZE to ascertain the line-mode screen dimensions and then proceed to use this size also. And then some apps use GTTERM to ascertain the primary and alternate screen sizes that the terminal supports, and choose one without inspecting the current line-mode screen size setting. And then again, some apps just proceed on the basis that the screen size is 24 by 80 without checking. Unless they have fixed it fairly recently, SDSF does not handle large screen sizes well (unless running as an ISPF application). Cheers, Greg -- 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: TSO TEST Debugging with TPUT and input paramters
Tony Harminc wrote: On 7 October 2011 16:34, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: (snippage) How do you direct the output of TPUT to another user from an unauthorized program? Same way it's worked since 1970 or so - issue your TPUT with TJID= on it. In newer OS versions, iirc 1980s, you can also specify the userid directly without having to do your own ASID lookup. The target user can choose not to receive your TPUT by using PROFILE NOINTERCOM. If you in turn want to override that, you do need to be authorized. (more snippage) Note that inter-ASID TPUTs from unauthorized programs have a plus sign inserted at the start of the displayed text - just like WTOs. Cheers, Greg -- 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: Fairwell to a Friend
Rick Fochtman wrote: Received from another list: -- To those who new him: Gilbert Sain-Flour passed away last night in Montauban France. He will be missed. Carlos Aguilera Sr, Sad news and a great loss. A man of great capacity and an incisive thinker, IMO. I never met him but we emailed a few times. He got me to take over talking to TSO/E support about a STTMPMD glitch under OS/390 2.4 when he no longer had access to that level. (The glitch did not manifest itself in other levels of OS/390). He suggested that if it ever suited, I should drop by and we'd share a bottle of wine. By the time I was visiting - Florida I think - he had relocated. Very sad now. Greg -- 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: running Assembler I/O macro code as AMODE 31, RMODE ANY
Steve Comstock wrote: The real issue is what LE uses to switch AMODE when the setting is AMODE31(OFF); it may be more than just a BASSM or SAMxx. I don't really know, but I somehow expect overhead and complexity in that scenario (COBOL interacting with non-LE Assembler, as specified in the OP) I've seen cases where shipped LE apps that work most places encounter program checks (once it was an infinite loop induced by a storage overlay) in the LE thunking layer at a couple of sites. Overridding local LE settings to ALL31(ON) seems to circumvent the problem. Cheers, Greg -- 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: Obtaining System Information from a COBOL program
Walt Farrell wrote: The system will do the checks for you at OPEN time, and any check your application makes may get the wrong answer in some set of circumstances. In my opinion it's usually poor application design to make a dsname check. You really should let the system do it for you, as it's going to anyway. Once upon a time I used to rely on the DCB abend exit to trap the S913 so that the program did not just abend without deallocating the data set. However, when I worked at an ACF2 site (years ago) the DCB abend exit did not receive control and the allocation was left dangling (because the program abended). So I added code like RACROUTE REQUEST=AUTH, ENTITY=$DSNAME, VOLSER=$VOLSER, ATTR=READ, DSTYPE=N, WORKA=$WKA, MF=(E,$RRL) and if that indicated a lack of READ access then I avoided the attempt at OPEN. Now this was non-VSAM so not exactly what was being discussed, but at the time it was a valid reason to do a check before OPEN did. BTW, does anyone know if this is still the case with ACF2? That is, does the DCB abend exit now get control if ACF2 denies access at OPEN time? Cheers, Greg -- 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: Reduced 3270 Screen Geometry
Paul Gilmartin wrote: This standard procedure is of little avail to the user who can't get past the I/O error to issue the SAVE and END commands. Surely issuing GTTERM would be a reasonable component of recovering from a terminal I/O error. When running pre-z software the TSO LOGON RECONNECT is less than perfect sometimes, so I put a GTTERM call in the screen reshow logic of REVIEW, and if the screen size has changed it passes that back to the browser/editor instead of just resending the lastest screen contents. It seemed to work well enough under testing. Cheers, Greg -- 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: Problems with TSO TEST
Ed Gould wrote: Just a point of curiousity Skip. Was it done by IBM Maintenance or done locally? I believe that IEFBR14 has always been in both SYS1.LPALIB and SYS1.LINKLIB for MVS. It has certainly always been there since MVS 3.8, and as a result of this thread I just checked and it is in both libraries in the MVS 3.7 starter system. I'd expect it in both for VS1 also, but am not in a position to check. Cheers, Greg -- 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: REVEDIT feature of TSO REVIEW command - ISPF-like EDIT in TSO READY mode
I suppose one reason you might want to use REVED (the alias of REVIEW which makes the default action edit instead of browse) is if the data being edited is too big to fit in your region. REVED will hold the data being edited in a data space which can grow to 2GB in size subject to local limits (both physical resources and locally customized settings). Admittedly you could logon with REGION=0M if you are allowed and get 2GB - common - high_private - (loaded_programs + program_data) minus anything else I forgot. When editing such large files, UNDO and REDO cannot be used, and response time for commands like FIND ALL may not be sub-second. Let's hope that we don't have to edit files that big... :) Cheers, Greg -- 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
CLOSE restore of DCB?
I always thought that the system took a copy of the pre-OPEN DCB, and restored it after CLOSE, with the possible exception of DCBBUFCB. After an OPEN and CLOSE of an EXCP DCB, the bits in DCBBFALN which flag the presence of a DCBE address in DCBDCBE have been zeroed. Assuming my observations are correct, any thoughts on whether this is a bug or WAD? Cheers, Greg -- 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: Detecting when a READ/GET crosses a concatenation boundary
Gilbert Saint-Flour wrote: Mike Wood said : check the value of DCBTIOT which is increased each time QSAM/BSAM start to read the next concatenated DD Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Is that due to EAV, or rather XTIOT? Dynamic allocation options that can be exploited based on new option in R12 Are you saying that in z/OS R12, DCBTIOT may no longer be updated when GET/READ switches to the next DD in a concatenation ? In the past 35 years, to detect this type of situation in my programs, I used the fact that DCBTIOT is updated. If it no longer happens, it would be a surprise ! Hmmm, well, I still use code which searches the TIOT the old-fashioned way, and if a DD is not found then it is assumed to not be allocated. If XTIOT catches on in a big way, this could be a problem too. Still, if we remember that XTIOT is a feature of dynamic allocation, then (a) JCL DD statement allocations will use the TIOT and not the XTIOT, and (b) if your program does the dynamic allocation then you control if the XTIOT is used or not. Also, it is safe to say DCBTIOT will still be maintained as expected when the allocation uses the TIOT. But, you can see that since the virtual storage address of an XTIOT entry can be more than a GB away from the start of the TIOT, the 2-byte DCBTIOT TIOT offset field cannot be maintained as we are used to when the relevant file uses the XTIOT. I guess I better stick to writing batch programs... :) Cheers, Greg -- 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: Detecting when a READ/GET crosses a concatenation boundary
Mike Wood wrote: Considering the future, and, hopefully, EAV being more prevalent in future, a better choice than DCBTIOT is to use DSABTIOT. Once the DCB is open, issue GETDSAB LOC=ANY,DCBPTR= ... and use the DSABTIOT change to detect the concatenation change after each GET. Mike Wood RMM Development Mike, Is that due to EAV, or rather XTIOT? Just wondering... Thanks, Greg -- 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: Delete all members of a PDS that is allocated
Ed Finnell wrote: In a message dated 6/25/2010 5:31:07 P.M. Central Daylight Time, rfocht...@ync.net writes: with Bruce Leland, the original author, for about 25 years. Author(s) Mike Smith and Bruce Leland. Big bloke with the red hair? Steve Smith. Most of the original ISPF interface was his work. I remember his presentation in 1990 when using PDS as a workbench was being encouraged. His pitch began Now, I don't know what your idea of a workbench is, but... and he showed a slide of a backyard shed workbench covered with as astonishing degree of clutter. I think he meant to imply that PDS offers lots of features and facilities. Cheers, Greg -- 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: Getting BIND/LINK date out of load module members
Frank Swarbrick wrote: On 5/20/2010 at 2:22 AM, in message 29s9v5lniuvtpalf97r7chtu7ogfmj7...@4ax.com, Binyamin Dissen bdis...@dissensoftware.com wrote: snippage Submit a requirement. No doubt. I'm just amazed that such a requirement wasn't submited 30 years ago. Frank 30 years ago IBM would have said (and IIRC did say) that those sort of timestamps are kept for the file, as other OSes keep such things for their files. (Granted, MVS keeps a reference data instead of a modification date.) Further, PDS members are not files, but parts of a file (physical files being called data sets in MVS parlance). If you want those sorts of timestamps kept in the file's data content, then make your application write such data when loading data into such a file. As has been stated, the linkage editor - program binder, and ISPF are two such applications which which write timestamps within the content of data written to their output files. Cheers, Greg -- 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: tso session timeout
Mark Zelden wrote: The records were written, just without (some of?) the CPU related data. MVS 3.8 had sequential SMF data sets (SYS1.MANX and SYS1.MANY with DCB=(DSORG=PS,RECFM=VBS,LRECL=1000,BLKSIZE=1000) even though some records - from MF/1 for example - could be longer than 1000 bytes). The assumed purpose for recording CPU time seemed to be for chargeback, which may or may not have been the real reason, but it seems aligned with facts such as there were no job-level SMF records written for started tasks, and jobs with TIME=1440 specified were considered to consume CPU free of charge. (Indeed, the Fujitsu clone of MVS showed the word FREE under the CPU time column on the console when an operator command like D A,J was issued for jobs with TIME=1440. Later maintenance removed this, again following IBM's trend.) Also note that messages IEF373I-IEF376I were not issued at all for started tasks. In fact, started tasks did not have SMF control blocks like the TCT at all, so there was no way to count EXCPs at the address space or DD level in the general case. The initiator checked to see if job/step timing limits were in effect and if not, branched over the logic to store the consumed TCB and SRB times. Recently (2007) I submitted a job on my free MVS system with TIME=1440 so it could run as long as it needed to. The next day I checked to see how much CPU it had used. Zero was reported in IEF374I (yes, the message was issued and showed the VIRT and SYS, but the CPU times were zero) and in SMF (yes, the records were there but the CPU time fields were zero), so I could not find out (although I could deduce it from the elasped time and the fact that it was CPU bound). As a result I developed a usermod to zap IEFSD263 to move the code around so that the CPU times are stored before the check about job/step timing limits is made. This allows the CPU times to be reported in IEF374I and IEF376I messages, and recorded in SMF record types 4, 5, 34 and 35. http://www.prycroft6.com.au/vs2mods/zp60019.txt Back in the day, along came MVS/SE2 (a no-charge but licensed enhancement) which introduced VSAM SMF data sets (the sign bit of CVTSMCA can used to test for this), SMF type 30 records, SMF interval recording, full SMF accounting for started tasks, logical swapping for the TI and TO swap reasons, the IEAICSxx member of PARMLIB and the SET ICS=xx operator command, transaction classes (job classes were used purely for scheduling before this), etc. From this time on TIME=1440 no longer suppressed the recording of address space CPU times. At least, that's the way I remember it... Cheers, Greg -- 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: CSV and Duplicate ALIASes
Paul Gilmartin wrote: Greg Price's tests seem to disagree with CC on this point. But it's possible my description was insufficiently clear, and Greg may have swapped the function of the alias and primary names. Yep, that's what happened. I took WOMBAT as the real name and FRED and JOE as alias names. That's why I said FRED and JOE got minor CDEs and WOMBAT got the major. I think the description was probably clear enough, but I read into it a situation which interested me more. (Tom M. also detected the incorrectness.) So, the tests were of interest to me, even if no-one else. :) Cheers, Greg -- 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: CSV and Duplicate ALIASes
Paul Gilmartin wrote: Suppose that (necessarily different) data sets in the programmer's STEPLIB concatenation contain: load module FRED with ALIAS WOMBAT load module JOE with ALIAS WOMBAT and the programmer issues: LOAD FRED LOAD JOE As the esteemed Mr. C has indicated, in the general case it's all stock-standard with CSV ignoring the fact that aliases are involved. It gets a bit more interesting when the modules are marked as RENT. After a LOAD of FRED, there will be a minor CDE for FRED pointing to a major CDE of WOMBAT. This will occur even if the directory entry for WOMBAT was deleted before the LOAD. That is, the WOMBAT can be resurrected in the JPA, and even used afterwards, simply by LOADing FRED. The directory entry for FRED contains the name, addressing mode, and entry point offset for WOMBAT, so the directory entry for WOMBAT is not needed to make the major CDE. Now suppose JOE the other WOMBAT is loaded. Again we will get a minor CDE for JOE pointing to a different major CDE also called WOMBAT. A request for WOMBAT will find the most recently loaded one. At least, this is what happens when I test it. Cheers, Greg -- 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: Long LLE list
Bernd Oppolzer wrote: I have the following problem: a piece of software that I'm not allowed to change due to legal reasons walks through the LLE list to look for a specific module. Any chance of purging the module from the LLE chain (via DELETE I'd expect) and then issuing a LOAD so that it is at the start of the LLE chain, and so would be found very quickly in any search of the LLE chain? Cheers, Greg -- 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: Determining if DUMMY allocation
Charles Mills wrote: Is there a way to determine if a DD statement has been allocated DUMMY, short of SVC 99 info retrieval? Sometimes I use the minimum call type of the DEVTYPE macro, and test for zeros being returned, as per the DFSMSdfp Advanced Services manual. To be pedantic, I suppose I am assuming that file is not a TCAM application process queue. The first fullword is documented as (hex) 0 - DUMMY (or that TCAM thing) 101 - TSO terminal 102 - subsystem eg. SYSIN, SYSOUT 103 - UNIX with the last three supporting a maximum blocksize of 32760. I'll have to try a DEVTYPE with /dev/null one day... Gil's remarks warn us that it may return the data for DUMMY, whereas is could be argued that it should return the data for UNIX. Cheers, Greg -- 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: Word-1 of the Conventional Save Area
zMan wrote: ISTR it was used by PL/I. That's what IHASAVER would seem to indicate. Cheers, Greg -- 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: Extracting STDOUT data from USS
Paul Gilmartin wrote: Why re-invent the wheel? I always thought that this came about because CICS was a DOS app later ported to MVS. This CICS smarts for managing virtual tasks and not really OS waiting until there was absolutely nothing else to do meant that CICS apps got great throughput under an OS which had no such thing as an SRM timer pop. Under DOS, (DOS/VS?) once CICS got dispatched it hogged the CPU until there was no more work left. Perhaps a CICS old timer can say whether this is true or not... ? Cheers, Greg -- 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: IEBUPDTE Supports Only LRECL =80 :-(
John P Kalinich wrote: PDSLOAD from the CBT (file 093) can handle LRECL =256. Regards, John K John, ITYM PDSLOAD can handle any LRECL allowed for unspanned fixed-length and variable-length records, although the sequential input file must have a minimum LRECL of 80 whether F(B) or V(B). Cheers, Greg -- 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: z/OS LOGON RECONNECT Recovery.
Years ago (circa 2000) I used Gilbert's IKJEFLN2 exit to great advantage to reconnect to lost sessions that were not deemed disconnected by VTAM. TSO/E (and even old TSO I believe) will happily tell any apps that ask about the current screen geometry. Initialized and running fullscreen apps are generally not set up (designed and coded) to cater for dynamic screen size changes. Whenever the VTAM page protection occurs (the three asterisks) a RESHOW code is sent to the fullscreen app so that it knows to repaint the whole screen. The default RESHOW key is PA2, and can be set to a PF key, but I cannot name a TSO fullscreen app which actually does use a PF key for RESHOW. Unlike a PA key which usually only does a short read, a PF key can also return typed text so using it for RESHOW could be considered wasteful. Perhaps the fullscreen app should perform a GTTERM whenever a RESHOW is encountered to verify that the screen dimensions have not changed? Hmm, sounds like a requirement for REVIEW... :) Well, reasonably doable for the browser, a bit messier for the editor. Perhaps a line mode dialog offering to exit with or without saving the data? Also perhaps including a RESET in case line commands were pending? Cheers, Greg -- 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: z/OS LOGON RECONNECT Recovery.
Woops! Sorry, wrong list. -- 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 to find statistics for fetched programs?
On Wed, 7 Oct 2009 13:56:48 -0500, Jan Vanbrabant wrote: But I couldn't dig up what I was looking for: will one of the reports display the CPU usage within each module? Jan, None of the reports you listed will show CPU consumption by program, because that information is not collected. Reported usage for a program will be the same whether it consumed a CPU minute or a CPU hour. Now, the reported usage will be different if that CPU minute (or hour) is spread over one invocation or one thousand invocations, but only in terms of use count. If those thousand invocations are from the one job, then that only counts as one job using the program. This is the sort of situation where the choice of report may become significant. [Note that the above is based Dorana/TAD4z whereas I will not attest to how usage reported by TLCMz is affected by these illustrative comparisons. It is possible that it is slightly different in terms of usage counts.] You're right that Dorana/TLCMz/TAD4z will report the use of programs even if they are not named on EXEC JCL statements. LLA exits can also do this, but only for programs fetched from LLA-managed libraries. I was thinking of a scheme of monitoring CPU time at the RB level back in the Dorana days if there was any interest. There wasn't. The idea was that the CPU time of an RB would be accumulated and logged against the name of the program that the RB pointed to. Note this this means that CPU time spent in programs that were simply branched to would be logged against the programs that branched to them. The scheme would have been strictly for TCB mode only, and so these days may be considered incomplete, and therefore misleading to some extent. Still, it never got beyond the idea stage, so I guess the technical issues are not a problem. Cheers, Greg -- 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: long parms...again
john gilmore wrote: snippage but in, say. current PL/I the single scheme embodied in example: procedure(parm) options(main) ; . . . declare parm character(*) varying2 parameter nonassignable ; . . . end example ; is the only one supported, snip I believe other schemes are supported, as documented by: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IBM3PG70/1.1.1.98?SHELF=IBMSH370 DT=20081017082717 (Line wrap will occur, no doubt. Search for SYSTEM in the PL/I Programmer's Guide.) Cheers, Greg -- 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 HELP Required.
Rick Fochtman wrote: In case you forgot: regular load modules only contain a note list if they are in OVERLAY format, which is both archaic and unnecessarily complicated. OVERLAY format does use a second entry in the NOTE list, but *all* PDS load modules have at least one entry in the NOTE TTR list to point to the first text block. I have, no doubt, forgotten lots of other things, though... Cheers, Greg -- 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 HELP Required.
Frank Swarbrick wrote: Everyone might be interested to know that there are some IMS datasets (I forget which) that *cannot* be PDSE. They must be PDS. Yes, PDSEs do not allow NOTE list TTRs in the directory entry. This is one reason why regular load modules cannot be housed in PDSEs. Cheers, Greg -- 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 to find statistics for fetched programs?
Rick Fochtman wrote: I know of a LLA exit written by Greg Price that can help with module counts. Thanks for the kind words, Rick. The LLA exit 1 concept is fairly straightforward (Rob Scott also did it in MXI) but only covers LLA-managed programs. To capture most program usage reliably takes a bit more work. If you are prepared to spend money you could check out the recently GAed Tivoli Asset Discovery for z/OS which happens to employ some of the Dorana technology I helped write way back last millenium. This product is also the logical successor to TLCMz, if I'm not mistaken. If you are not prepared to spend money then the LLA exit approach can still yield interesting data for your site, and the more libraries you LLA-manage the more data you could get by that method. (I used the LLA exit as part of my IMON system monitor thingie to get real-time stats displays in 1995, much as Rob later did with MXI.) Cheers, Greg -- 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: IEFBR14 (was: EXEC Above the Bar)
Gilbert Saint-Flour wrote: I also remember a special version of such a utility that was called IEFBR15. My version of IEFBR15 just looped. :) Cheers, Greg -- 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 are the device codes (returned by LOCATE) defined?
Tom Marchant wrote: On Mon, 27 Apr 2009 09:59:51 +0300, Binyamin Dissen wrote: Do all products (HSM, FDR, etc.) use the string MIGRAT as the VOLSER? FDR does. Actually, it's ABR. ISTR that this behavior is optional, but I don't recall what is in the VOLSER if the option is not selected. The original VOLSER perhaps. Another point to note is that ABR sets the high-order bit on in the DSCB CCHHR field of the catalog entry when the data set is archived and the original volume serial is retained. I do not know if this bit setting occurs or not when the volume serial of MIGRAT is used. I believe that the usual restriction of VTOCs must be in the first 64K cylinders of a volume must therefore become VTOCs must be in the first 32K cylinders of a volume when ABR (without MIGRAT at least) is used to archive data sets. I would guess that all volumes had less than one thousand cylinders when this logic was devised. Cheers, Greg -- 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: TCPJPQ is null
[EMAIL PROTECTED] wrote: At this shop that I work with, there was a program that used TCBJPQ as a ptr to loaded modules within the address space. One problem though, it was abending since TCBJPQ was null. No problem though, I devised a different solution using CSVINFO. Question, what was TCBJPQ null to begin with? We are running zOS 1.9 Thanks Two obvious things come to mind: (1) No programs were loaded in the JPA (perhaps the program was moved to LPA). (2) You were not looking at the relevant job step task. -- 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: TCPJPQ is null
On Fri, 28 Nov 2008 15:02:46 -0800 (PST), [EMAIL PROTECTED] wrote: Hi The programs were normal application key 8 programs. As for the job task, I started at PSA, via PSATOLD, went to TCB, and TCBJPQ was empty. TCBLLS was populated though... Thanks PSATOLD-TCB TCBJSTCB-TCB (I think you skipped this step) TCBJPQ-CDE chain TCBJPQ could still be empty if all normal application key 8 programs were reentrant and resided in LPA. TCBLLS can point to an LLE chain with each LLE pointing to an LPDE or CDE describing an LPA program, so there would still be an empty JPA. OPEN macros typically result in LOADs for LPA programs, for example. Cheers, Greg -- 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: Cancel tso id - IKJEFLN2
Paul Gilmartin wrote: On Fri, 21 Nov 2008 07:56:01 -0400, Shmuel Metz (Seymour J.) wrote: Interesting: o With Peter DiCamillo's X 3270 and a nonstandard screen size o I make a tn3270 connection to VM o From there a VTAM connection to z/OS o I start SDSF from the TSO READY prompt o Line commands are ignored. o I exit with PF3 and start SDSF under ISPF. Line commands work. -- gil Hmmm, sounds like your screen had more than 4096 locations. If it did, all inbound buffer addresses are in the 14-bit format. SDSF probably only handles 12-bit addressing, both in and out, but if the entire screen is repainted consecutively then the only output buffer address you need is location zero. The input parsing could probably be fixed with two extra instructions (a TM followed by a BNO or JNO to skip the 12-bit decoding acrobatics). Under ISPF, ISPF handles all the 3270 dependencies for apps such as SDSF. Cheers, Greg -- 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: IGGCSI00 error -- only returns values for 1 of 3 attributes -- any help appreciated
Chuck Haatvedt wrote: Just a bump on this to see if anyone can give me some assistance on this . thanks, Chuck Haatvedt Chuck Haatvedt wrote: I have written a small COBOL program to call the catalog search interface module. I pass three attributes to the program and it builds the output area with the three sets of values being returned. However 2 of the 3 areas always contain high values instead of the LRECL and NOBYTUA (block size ?). Is this by chance a RACF authority related issue ? No real clue here, but I wonder... Are the data sets VSAM data sets? If not, does the CSI check the VTOC for the values you request? Or can it only return data items that are stored in the catalog? Cheers, Greg -- 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: Compression figures, anyone?
Paul Gillis wrote: G'day Greg, Thought I would take the opportunity to run a quick test on a z800. Copying a 108 track SMF dataset. 1. Using ICEGENER without compression 9 CPU seconds into 108 tracks. 2. Using ICEGENER with compression 30 CPU seconds into 76 tracks. 3. Using ISPZIP compression 78 CPU seconds into 8 tracks. Thanks for that very interesting info, Paul - as well as the dictionary lookups! (Obviously the best part of your timekeeping was exhibited in your sign-off.) OT: Thanks also to an off-list responder - verizon.net blocks emails from my IP address because it is thought to be a source of SPAM. And YAPG (Yet Another Paul G. - Gil) was pretty right on in another thread about what I was looking for in having zip files supported. Cheers, Greg -- 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: Browsing an ASCII file
Neal Eckhardt wrote: I want to browse a UNIX file in ISPF and have the characters display as ASCII characters, not EBCDIC. I thought I had done this before about half a decade ago, but I can't seem to find out how I did this. What am I missing, or is my memory failing me? I'm usually pretty good remembering something when I see something and say COOL to myself. I can browse the file in the ISPF shell, it's the translation part I'm missing. Neal Well, REVIEW has had ASCII browsing for 21 years - were you thinking of that? Probably not.:-D Admittedly, UNIX file browsing - including ASCII - was only added about 8 years ago, and ISPF app-ness only 5 years ago. No doubt, ISPF does it better now, but still, the price was right... :) Now all we need is support for ZIP archives. GP -- 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
Compression figures, anyone?
Hi. My semi-facetious remark about ZIP archives got me wondering about what sort of compression ratios users of compressed extended-format data sets are getting. Zipping text can get 75% to 90% compression (ie. reducing the data to 25% to 10% of its size). How's that compare? Of course, no matter what the size reduction is, I'd expect it to use a lot less CPU time than a zipping app. So, anyone care to share? TIA, Greg P. -- 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: Browsing an ASCII file
Mark Zelden wrote: On Fri, 5 Sep 2008 18:30:55 +1000, Greg Price [EMAIL PROTECTED] wrote: Now all we need is support for ZIP archives. We or Review? ;-) We already have it with Java - which is free. Sorry - I wasn't clear. I meant the ISPF Browse (nice) and ISPF Edit (even nicer) support for processing files within a ZIP archive. But, probably no business case You can already browse zipped data with REVIEW (plus util) online, and copy some or all unzipped records to a data set. That's free also. :) Cheers, Greg -- 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: Compression figures, anyone?
Paul Gillis wrote: Greg, I used to get about 80% when zipping SMF data, haven't done that for a while and never considered the CPU cost as I had to get the data under 2Gb. The reasons are now obsolete. The zip engine I used on MVS was ISPZIP from ASE. I may still have the performance numbers somewhere. Cheers, Paul Gillis Hi Paul, Yes, I've seen that software used to great effect for years, also. And I see that Scott has posted about the advantages of zipping SMF data. All great stuff, and I concur completely. What I was really fishing for was user experiences with using DFSMS compressed extended-format sequential data sets. And if that doesn't trigger a response, perhaps we can start a thread about compressable (as I recall seeing in an IBM manual) vs compressible (the spelling a spell-checker (MSWord?) okays). As I may have said, I would expect the latest and greatest z hardware to be able to deliver compression ratios comparable to zipping in only a fraction of the CPU time. Maybe the CPU time aspect is hard to measure, and I don't think zipping is that much of an expensive process anyway, but I _am_ hoping that someone can report of the level of compression being achieved. If I tell people that using compressable extended-format is a superior solution to zipping files in terms of overall computer resources (with disk space being a large part of that), am I telling fibs? Cheers, Greg -- 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: TN3270 *from* a host??
Hunkeler Peter , KIUK 3 wrote: TSO TELNET is not a TN3270 client, it supoprts only line mode. I think it's safe to say the the TELNET command accessible from the READY prompt does support TN3270. At least it is possible to use it to telnet to another z/OS and get the VTAM logo and logon to TSO and crank up ISPF in all of its 7-colour glory. Cheers, Greg -- 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: RES: Sequential compressed (on disk) - how to tell?
ITURIEL DO NASCIMENTO NETO wrote: I Don't know if you can get this information from DCBE, but it's available in Format1 DSCB. TMDS1FLAG1,DS1COMPR JORETBUFNO Ripper. You know, I looked there but obviously missed it. I guess it's OBTAIN time. Thanks, Greg -- 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: Stupid Question of the day.
Paul Gilmartin wrote: If some future release (or a USERMOD?) were to remove not just SYSIKJUA propagation, but to remove the ENQ entirely, might it then be possible for a user to have concurrent sessions not only in different LPARs, but even in a single LPAR? The MULTITSO package in CBT file 134 appeared when the millenium was young, and JES (at least JES2) only allowed one TSU job of a specific name to run at a time. It works by front-ending the ENQ SVC and converting SYSIKJUA enqueues to shared. Also, exits step in to alter the job name in the TSO session's JCL. This permits 40-ish concurrent TSO sessions from a single TSO userid. CLISTs invoked at LOGON time used an ISPF profile with a qualifier of the job name, cloning it from the user's master copy if it did not already exist. Good for a single system, but not SYSPLEX aware. Still, I think it proves your point. Cheers, Greg -- 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
Sequential compressed (on disk) - how to tell?
Howdy do. When I have an open SAM DCB (OUTPUT, if that matters) I want to be able to find out if the data set is a DASD compressed data set. Can this be done? AFAIK, compressed sequential data sets must be extended-format data sets, but extended-format data sets do not have to be compressed data sets. When using a DCBE with the DCB, DCBENSTR can be tested and if zero the data set is not extended format - and therefore I think can't be a compressed data set. But, if DCBENSTR is non-zero, then the data set is an extended-format (and therefore DASD) data set, but can I tell if it is a compressed data set or not? (I only mention DASD explicitly here so we don't go down the tape compaction cul-de-sac.) Thanks a bunch. Greg -- 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
LRVH instruction - misnamed or BAD?
LRVH - Load Reversed (Halfword) So it should load a reversed halfward, right? Well, sure, it swaps the byte order (compared to their order in storage) and puts them in register bits 48-63, **BUT** it leaves bits 0-47 UNCHANGED. Now, that last part is not what LH does, is it? In my book, that's an INSERT, not a LOAD. I think it should have zeroed bits just like LH does. I think the LOAD (as I envisage it) function is more useful than the INSERT function (as it is implemented). Am I right or am I right? (They are the only possibilities, aren't they?) Cheers, Greg -- 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: LRVH instruction - misnamed or BAD?
McKown, John wrote: Yes, I'm sure the sign bit is in the middle as viewed in Intel storage. The point that the OP was making is that the LRVH is misnamed because it does not touch bits 0-47 of the 64 bit register. It acts more like an insert than a load. Exactly right. But thanks to Steve and other for pointing out the difference between zeroes and sign extension. The original post was triggered by the use of LRVH in the mistaken belief that the byte order was the only difference from LH. When a positive number was loaded with it, the low-high halfword of the register still had the residual mixture of bit settings. I thought the word Load in the instruction name implied a clearing of previous data. Next time: don't think - read. Cheers, Greg -- 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: MVS booklist again
Bruno's book has been OCRed and can be downloaded from http://www.prycroft6.com.au/misc/ (currently last item on the page). At under 4 meg it is a fair bit smaller than Bruno's original scan, but could not have been created without it. Thanks, Bruno! Cheers, Greg -- 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: OS/2 Lost but not forgotten by IBM
Gary Green wrote: Tis a real shame... We still run four boxes with various flavors of OS/2. Hey, aren't you the SMF-for-OS/2 guy? Hmm, or was that SYSLOG? Yes, SYSLOG, I think... :) Nice work... Cheers, Greg (OS/2 user of years and years ago) -- 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: DSLIST DELETE VSAM Dialog
The other point to mention about migrated data sets - even VSAM components/clusters - is that their MIGRAT catalog entry is always non-VSAM, which explains why ISPF does not crank up any dialog related to VSAM deletion. Cheers, Greg P.S. Season's greetings to all. -- 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
3380 vs 3390 (was: IBM RAMAC now an URBAN Legend:( )
Paul Gilmartin wrote: Ummm. Imagine the effect on a dusty JCL deck which said, DD SPACE=(CYL,100). But perhaps not. ISTM that SMS or DYNALLOC (or maybe even ISPF) sometimes adjusts my requested SPACE to account for the difference between 3380 and 3390. I believe there was a panel in the ISMF dialogs where the nominal track size was specified. If the value there was 47047 (or whatever the correct value for 3380 is) then when one requested an SMS-managed data set that specified a number of tracks or cylinders, the requested space was allocated if a 3380 was used, but a different space was allocated if a 3390 was used. Changing this track for 3390 made the space correct for 3390 but a larger number of tracks was allocated if a 3380 was used. Or so the story goes... Cheers, Greg -- 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
31-bit I/O macros - anyone remember when?
Hi. It is my recollection that when MVS/XA first came out the usual suspect group of non-VSAM I/O macors (GET/PUT/READ/WRITE/CHECK etc.) could not be issued when AMODE was 31. Now-a-daze AMODE can be 31 when issuing these macros, and this has been the case for years. My question for those with better memories than mine: When was this enhancement added? I expect it had more to do with DFP or DFSMS than BCP, but don't let that affect your recollection. Thanks, Greg -- 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: 31-bit I/O macros - anyone remember when?
Roland Schiradin wrote: Hi Greg, OPEN/CLOSE support AMODE 31 since DFP 2.3 (FMID HDP2230) PUT/GET support AMODE 31 since DFSMS 1.1 (FMID JDZ1110). This was the first release of DFSMS. Roland Hmm, that would seem to put the non-SVC macro upgrade around the SP4.3 to SP5.1 time frame. Thanks a lot, Roland - you're a champion! (but everyone knew that...) -- 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: Multiple TSO logons (was: Patents, ...)
Paul Gilmartin wrote: On Thu, 14 Jun 2007 20:30:43 -0500, Tony Harminc wrote: I've looked at this, and it isn't pretty doesn't even begin to describe it. Unless IBM has severely modularized things since the last non-OCO version of this stuff, it is full of hardcoded knowledge of not only VTAM (and TCAM!) module names, but of their various quirky behaviours. So how does IKJEFT01 in batch bypass all that stuff? How does it bridge the userid==address space name pitfall? -- gil Some of the things that rely on userid=jobname probably include inter-ASID TPUT (incl. OS SEND command) and LOGON RECONNECT. If you are not fussed about those two things (and anything else that I should have listed) then it is easy to allow a single TSO-authorised userid to logon to TSO multiple times concurrently on a single MVS image. (Stroking chin for flashback sequence...) It all began because for years I wanted the RACF user name (of up to 20 characters) to be placed into the programmer name field of the JOB card of the TSO session's JCL. I complained about this somewhere - maybe even here - and whined about a RACF deficiency when compared to ACF2 which does do this. Walt the RACF wizard kindly pointed out that this is not up to RACF to do but TSO. So, whipping up a TSO Logon Post-Prompt Exit (IKJEFLD3) from the sample, the RACF user name went into the JOB card. Nice. Now, for my next trick, I change IKJEFLD3 to fiddle the job name by adding a character after the TSO userid (which has a max length of 7 chars) to form the new job name. This allows up to 40 TSO user address spaces from the one id (blank or TSO classic, 26 alphabetic, 10 numeric, and 3 national). Oh, and of course the other thing to handle is the SYSIKJUA ENQ on the userid. This is deftly dealt with by cunningly converting these ENQs to shared (instead of exclusive) - achieved by a simple front-end to SVC 56. Warning: the way I did it makes no allowance for SYSPLEX or shared SPOOL (Didn't JES2 enforce unique TSU job ids in a MAS? Was this ever changed?) because the decision of which suffix character to use for the job name is made by scanning the address space names in the virtual storage of *this* system only. It all seemed to work okay but it was OS/390 and not the most heavily-loaded system in the world (although I still think it would work on z/OS and I don't think system load affects it's viability). And as I say, the ability to LOGON RECONNECT goes out the window, which may not be an issue if you use session manager software or have a reliable network. And as far the ISPF profile data set, we settled on a scheme where the session's profile data set (perhaps userid.jobname.ISPPROF) was cloned from the user's original or base profile data set by the logon CLIST. It may have even been deleted and cloned anew each time so that updates to the base profile got promulgated. And I may have even written a function which returned the current job name into a CLIST variable. The method is described in member MULTITSO of CBT file 134. The JCL and source code for the TSO exit and the SVC 56 front-end and its loader are also present in other members of that file. And that was about six and a half years ago... (stops stroking chin). Cheers, Greg P. -- 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: Patents, Copyrights, Profits, Flex and Hercules
Phil Payne wrote: Then there was Nestle Frankfurt, who wanted both CPUs to have the same serial number. BS3000 was pulled because Fujitsu (deservedly) lost a court case. One of the settlement conditions was the withdrawal of BS3000, another was $600 million, if memory serves. At the time, I not only expected it but felt it long overdue. Served 'em right. AIM was an affront to IBM. I'll bite. Of all the things that could be an affront to IBM, why did you pick AIM? AIM - Advanced Information Manager - was the DBMS Fj developed for their own OS (X8) and then ported to their MVS clone (F4). IIRC it was a network data base, not heirarchical like IMS, not relational like DB2 (although later there was an AIM-RDB), and so probably not copied from anything IBMish at all. Unless you do mean AIM-RDB, which I wouldn't know if it was DB2-like or not. Just wondering... Greg P. -- 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: Data Areas Manuals to be dropped
Thompson, Steve wrote: Folks: Just in case some of you weren't around in the mid-80s doing development and the like, IBM decided to go OCO (we will drop the cause of this decision) and the CEO (Ackers - if I remember the spelling of his name) promised that nothing would go OCO until it had been correctly documented. NaSPA was hot on IBM about this and many of us watched as this promise was, well, given short shrift. I think I've still got my Just say NO to OCO T-shirt that I bought at a NaSTEC. I wore it the next year but the NaSPA hard line against OCO seemed to have evaporated. A NaSTEC attendee pointed to my T-shirt and asked what OCO stood for. How quickly we forget... :) Cheers, Greg -- 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: Top 10 software install gripes
Pinnacle wrote: Tom, I tested this in the old days of SLED DASD, and the directory was a keyed track and you COULD NOT store a member in the directory track. It always took 2 tracks minimum for a PDS (of course, this has not been true for about 15 years). Regards, Tom Conley -- Tom, I agree with (the other) Tom - I don't think this has ever been true. I just tried making a member in a new single track PDS under MVS 3.8 and it worked without a problem - and that software is more than 20 years old. There would be an increased statistical likelihood that the first member would start at the start of a track because it is possible that there is not enough room after the directory to fit a data block on the last directory track. But there seems to be nothing to prevent it in general - which is good because that matches my recollection from those times. BTW, on the cylinders vs tracks allocation point, I think that if a data set is allocated in cylinders then the access method can use the MT bit (the Multi Track bit is the x'80' bit in the CCW opcode) when building search channel programs, thus reducing CPU overhead and the chance of RPS miss. For example, for search-key-equal-or-high, a x'69' CCW can search a track, while a x'E9' CCW can search till the end of the cylinder. Note that the end of extent being on a cylinder boundary is important, not that the extent starts on a cylinder boundary. At least that what I've heard. Mind you, I think this is all superceded by ECKD now-a-days. Cheers, Greg -- 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: How recover from unrecoverable DCB ABEND?
In my meagre experience, abends such as EOV which are normally recoverable in QSAM I/O (which I guess means GET and/or PUT, oh and PUTX of course but that should be unlikely given that PUTX is an update-in-place of a successfully read record) become unrecoverable when the same condition is encountered under the auspices of OPEN or CLOSE. So, given the comment that the problem may well have occurred while attempting to fetch the first block, I'd say that in this case the problem was encountered under the OPEN SVRB. If you find that a SYNAD exit can handle the situation, then well and good. But I think it was said that a SYNAD exit was employed to no avail. To me, the suggestion of an ESTAE with a RETRY made the most sense, in terms of attempting to recover from the abend with some degree of grace, but I don't know the details of how RETRY from an ESTAE works when the abend occurs in an RB invoked from the PRB which issued the ESTAE. It's almost like run-of-the-mill I/O hassles which can normally be handled and recovered from become unrecoverable when they occur when a complicated RB structure including non-problem state RBs such as SVRBs exists. Hey - (slaps hand on forehead) - maybe that's why the DCB Abend Exit is given flags to indicate an unrecoverable abend... So, in summary, given that SVRBs are running with a determination to abend the current task, I think only mighty strong ESTAE magic with more sophistication than is usual can forestall the event. Probably not the news you wanted to hear... Sorry.:( Cheers, Greg -- 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: Bypass Update of Last Used Date in OPEN (was EXCP with a DEB)
Steve, Too late - check out IHAUDA in SYS1.MODGEN. Cheers, Greg -- 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: ECSA
I've heard of that some places are desperate to get every KB of extended private area they can, but I've never worked at one. So usually I like to see between 50MB and 200MB of ECSA sitting around just in case. Then, if an ECSA hog comes along you have room to move. Such a hog (of varying degree) might be a new product you have to install which uses some ECSA, but these days you don't want to have to IPL to activate it, even in a test or development LPAR. I'd tend to agree that normally a GB of ECSA is too big. Also, I like to see the COMMON page data set big enough to back a fully populated CSA+ECSA, though some subpools of CSA are page-fixed, so I guess pages in these subpools will never be paged out. Cheers, Greg P. -- 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: PDS Unload Using IEBUPDTE
Really Jim? You surprise me. BTW, Release 40 of REVIEW should be out in a week or two. :) GP Jim Marshall wrote: Snippage. You can thank Bill Godfrey for getting everyone started in many more utlities besides LISTPDS. Jim Marshall -- 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
LINK * command broken on 1.7?
Is it just me or is the TSO LINK command broken under z/OS 1.7? LINK * NCAL LIST PR(*) etc does not seem to give much opportunity to enter control statements. The TSO HELP for LINK seems to be updated recently, so maybe they did some work on it. And some reckon TSO is dead :) Mind you, if bits which have worked for decades stop working I suppose it might be soon. :( Or have I made some basic mistake? Cheers, Greg -- 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
LINK * command broken on 1.7?
OA13194: TSO LINK COMMAND DOES NOT ALLOW TO ENTER CONTROL STATEMENTS Of course, I could not find the APAR until I posted the previous message to the list. Oh well... -- 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: Search for text in load modules
I've found that the PDS command (CBT file 182) does an excellent job of dumping a bit of data around the found text. Even tells you the CSECT. Cheers, Greg [EMAIL PROTECTED] wrote: Hi fellow listers, I'm trying to find the value listed after the text string REL= in all load modules in a PDS. -- 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: CBT Delinker
Makes me wonder what sort of differences present. Presumably various CSECT and entry point names match or you would dismiss the modules as completely different immediately. Same with CSECT sizes. I can only think that the CSECT order is different in the two modules. For programs with a large number of CSECTS it would be tiresome to compare. If this is the problem then how about relinking with a series or ORDER statements which nominate every CSECT? Then the two different versions could be made to order the CSECTs identically, and the link edit maps should be more easily compared. Or perhaps there was another problem? And you are also saying that a TXT record with no TXT should not be. Makes sense to me. I'll pull the source and see if I can spot it. (I haven't seen the author for years, but he's probably around somewhere.) Cheers, Greg [EMAIL PROTECTED] wrote: And now, I have the problem of validation. When I run two Binder steps with inputs respectively the original load module and the output of DELINKI (with empty TXT record removed), the load maps are more different than I can readily reconcile. How might I assure myself that I'm getting an equivalent load module? Thanks, gil -- 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: How to Initialize a BDAM file
[EMAIL PROTECTED] wrote: Could one use a modest size data set and concatenate it with itself multiple times? Yes, that would work. Could one use EXECIO in a Rexx EXEC, in which case no source data set whatever is necessary? This depends on whether EXECIO tolerates DSORG=DA. Perhaps EXECIO always uses SAM (to an OS non-VSAM data set anyway), so DSORG=DA in the VTOC entry should present no problem. If IEBGENER works at all, presumably one could write an EXEC with a POSIX pipe allocated as IEBGENER's SYSUT1, and again avoid the need for a source data set. Quite likely. Or one could use a data generation utility like IEBDG as Ewald suggested. There are so many options I'm surprised the OP had any problem at all.:) Cheers, Greg P. -- gil -- 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: SMP/E SE37 Retry and ++ZAP
Know of any good delinkers at cbttape.org? I think David Noon's delinker in CBT file 90 is pretty powerful, as long as your not talking about program objects. I haven't looked into it fully, but you may even be able to get it to wrap MCS around the object decks. It handles the various reusability levels, APF settings, and AMODE/RMODE settings, although it would pre-date AMODE64. It's written in PL/I so maybe AMODE64 could be added fairly easily if required. Cheers, Greg -- 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: Is VIO mandatory?
Years ago I found directing compiler (PL/I and Assembler) work files to VIO could reduce the elapsed time of a compilation to a fraction of what it otherwise would be. May not be true now... or systems are so fast it doesn't matter much anymore. The big advantage of VIO that I still like is the fact that no VTOC entries are created, and no DASD device allocation occurs. When a system crashes there is no dead disk space awaiting HSM or whatever cleanup a few days later, assuming you have it configured to do that. I'm one of those that likes to have the ISPCTLn and ISPLSTn files in the LOGON proc to avoid most of those SPFTEMPn data sets clogging up the works. I allocate them to VIO which avoids space fragmentation of temp d/s vols, and does not cause allocations which may inhibit DASD admin things I might want to do when I'm the only one logged on (and using ISPF). (I notice that the AD/CD systems have ISPCLT1 and ISPCLT2 in the LOGON proc(s). I doubt these files would ever get used.) It's great to be able to use UNIT=SYSALLDA in vendor or freebie code - very glad IBM supplied that one - but alas there is no universal VIO unit name. I usually first attempt allocation to UNIT=VIO and if that fails - maybe with INVALID UNIT NAME - I retry the allocation with UNIT=SYSALLDA. For these sorts of (usually TSO) apps, I'd expect that often none of the data in the VIO data set would have to leave central storage - I/O avoidance in action. VIO is the go! :) Cheers, Greg P. -- 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: miniunz
Mendelson, Eric wrote: I need the load module for MINIUNZ used by the Review command Both MINIZIP and MINIUNZ are in CBT file 135 from http://www.cbttape.org/updates.htm -- 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: HSM control dataset control block map's
Miklos Szigetvari wrote: Hi Thank you, I would need in machine readable format , I would need them in a program Start typing. (That's what I did.) -- 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: IEFACTRT modifications
IEFACTRT can use a system routine (IEFYS?) - usually link edited in - to write to the messages data set (where the COND CODE is) without having to worry about WTO routing codes and SYSLOG or console effects. That's what most flower boxes use. Many places use IEFACTRT to issue WTO messages reporting the step completion results for job log and/or syslog reference. After the demise of the I/O count zap usermod I resorted to using IEFU83 to trap SMF type 14/15/64 records to report EXCP counts against each data set. Without the ability to use IEFYS in this exit I had to use WTO with ROUTCDE=11 to get the info to the messages data set. I did not want all batch data set activity logged to the syslog, or even reported in the job's own job log. Fortunately, though IBM taketh away it also giveth. OCO prevented (for practical purposes) an updated I/O count zap hack but MPF had been introduced. So, a few simple bit switching MPF exits allowed the messages issued by my IEFU83 to show up in the messages data set without clogging up the job log, syslog, or console(s). The same could be done for any WTO messages from anywhere (given known message ids). The messages also go to the Master Trace Table if that is a consideration for anyone. It wasn't for me. In fact it provided a nice place for me to observe how many messages my exit was producing system-wide. Cheers, Greg -- 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: z/Architecture Principles of Operation (SA22-7832-04)
Ah, yes, how to get an opcode and two Y-format operands into a single 6-byte instruction :) Thomas Berg wrote: Have anyone used the long-displacement facility instructions (as in consistently do so to reduce base register usage) ? Are there any pitfalls or limitations that a relatively inexperienced programmer should be aware of ? Btw, why is there no MVCY instruction ? Is it because of the existence of the MVCL instruction or .. ? -- 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
Question for REVIEW command users re RLS
Hi. If you do not use the REVIEW TSO command then you can skip this one now. I'm just wondering if anyone using REVIEW to browse VSAM data sets has ever had any RLS issues. Did RLS cause some VSAM read failure by REVIEW? (Was the RC/REASON reported by REVIEW?) Did you get any data from the data set, or was it all inaccessible? Can you reproduce the scenario at will? Whoops, I should have said questions, not question in the subject. Replying to me rather than the list would reduce list clutter I imagine. You can use my unscrambled address from circa 28th Aug, (dunno what happened that day, but later posts were scrambled again) or gregp hat prycroft6.commercial.australia should work for the next little while (abbreviate the last 2 domain qualifiers in the standard internet way before sending, and hat does not mean headwear here). Thank you for your indulgence. Cheers, Greg. -- 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: IFIND
TISLER Zaromil wrote: They are functionally equivalent. If I try IFIND in SDSF under SE or SJ, the cursor jumps to the first (non-blank?) character in the next line, not to the next occurrence of the string. if I try IFIND under SB nothing happens (the cursor does not move). When I fiddled with writing an ISPF app and wished to implement a repeat-FIND function, I could not gain access to RFIND. RFINDis not active was the message I got, and so, inspired by SDSF, I decided to use IFIND for my repeat-FIND function name. AFAICT RFIND can only be used by ISPF builtin facilities like BROWSE, EDIT and VIEW. I think this is why SDSF does not use RFIND as the command name. I think SJ, SB and SE invoke ISPF's Browse or Edit, so RFIND is available for them. I could not get IFIND to function whenever RFIND was functional, although IFIND was not flagged as an invalid command at those times. Now, once the application is informed that a repeat-FIND is requested, how it handles it is up to the application. I tried to follow EDIT/VIEW/BROWSE logic when positioning the cursor and the data in my app, but SDSF seems to position the found text to the top data line. QUEUE did that, but then started the search from the second line, while SDSF seems to be cursor column sensitive, and so an IFIND can find another match on the top data line if it is past the current cursor location. Sort of a ISPF-QUEUE hybrid, it seems to me. Or maybe they wanted the details on the top screen line like line number and DSID to petain to the found text. Hmm, maybe they're not so silly after all. :) Cheers, Greg P. -- 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: Reading a PDS (why couldn't you have just said Read Count?)
Shmuel Metz , Seymour J. wrote: There is no such thing as a fake residual count, What would you call a value calculated from the BLKSIZE and the count area and plugged into the CSW field of an IOB? That sure sounds like a fake residual length to me. For example, with variable-length records the residual count in the IOB for BSAM/BPAM is DCBBLKSI minus the length in the BDW, even if the BDW length indicator is zapped to be smaller than the actual length of the block. I was going to report whenever the BDW indicated the wrong length when compared to the length ascertained from the residual count in a program once, but then found out that such an inconsistency was not really possible. Cheers, Greg P. -- 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: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
[EMAIL PROTECTED] wrote: In a recent note, Greg Price said: Date: Wed, 1 Jun 2005 14:16:51 +1000 Well, here's my theory: Does this have to be done by theory and/or experiment, or is it made clear in the documentation? I believe theory/experiment/doco all agree on how the system behaves here. The theory reference is due to me not having access to the current source of IEBGENER. I'd say your outline of the SYSUT2 DCB Open exit (which need bear no similarity to the exit for SYSPRINT) sounds pretty right. I was going to suggest that experiments with SYSOUT are not relevant to illustrate DCB processing, but Ed J said it first. Hence my passing remark about a real line printer. Allocating a real unit record device takes the dummied up DCB facade of JES ACB processing out of the picture. IOW, I was trying to think of a device where QSAM/BSAM could be used that was not TAPE or DASD to illustrate a currently available non-SDB example. Programs that will abend with S013-34 when the output file is on TAPE or DASD will often not abend when the output is directed to SYSOUT because of its forgiving nature. I haven't done much JES3, but JES2 does not seem to care about DCBBLKSI remaining zero at all (it still remains zero after OPEN whereas SDB will put a non-zero value in it). I have not checked the doco re your point about the exit getting control before or after the SDB is filled in. Experiment indicates that the exit ends before the OPEN-time SDB is supplied. Therefore, a run-of-the-mill IEBGENER step can produce different output blocksizes depending on something as simple as whether DSORG=PS is specified in the JCL or not. It's been a while, but IIRC I used to have ACS routines which set DSORG=PS for DASD data sets whenever a null DSORG was found at creation time. For data sets that were never opened this used to allow recognition that they were empty as well as HSM migration. But yes, if the DCB blocking has been determined by the user or by allocation-time SDB, IEBGENER's DCB Open exit has nothing to do about setting the output blocksize. My surmise about allocation-time SDB is really just me parroting back the publicity around at the time SDB was introduced. Since behaviour matched what I was told I've never checked the manuals on it. I expect DFSMS: Using Data Sets to talk about the OPEN-time SDB, and DFSMS: Implementing System Managed Storage (SC26-7407-02) to talk about the DADSM end of things including allocation-time SDB. I suppose it might be nice if each had a pointer to the other if they don't already. Cheers, Greg -- 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: SDB, BLKSIZE=0, and IEBGENER SYSPRINT
Bob Wright wrote: You're welcome. I thought that we'd bumped into something like that in the course of some service aids development where we had an old DCB that didn't specify DSORG, leaving that for a DCB OPEN exit to supply. I have no idea why IEBGENER would be going that route, but it certainly needs to be available to OPEN before a DCB OPEN exit to implement SDB. Well, here's my theory: Once a DD for a NEW disk data set has the following DCB attributes 1) RECFM specifying fixed-length or variable-length records, 2) LRECL more than zero 3) DSORG of PS or PO 4) BLKSIZE of zero THEN a System-Determined Blocksize (SDB) is placed into the data set labels during data set creation, way before OPEN happens. In fact, OPEN won't happen if PGM=IEFBR14, for example. SDB will not occur unless the DSORG is known to be PS or PO. During OPEN the DSORG _must_ be known, so SDB gets another chance to run if BLKSIZE=0 is still true (for PS and PO). Re IEBGENER, it seems that IEBGENER will use any valid blocksize in the data set labels before OPEN, including an SDB set during data set allocation, for the SYSPRINT file. I'd guess that IEBGENER has a DCB OPEN exit on SYSPRINT which, when it gets control, checks the BLKSIZE value in the DCB. If it is zero then BLKSIZE is set to LRECL (ie. 121). Logic such as this is very useful for preventing OPEN abends where no DCB attributes are coded in the JCL for new data sets while still allowing the BLKSIZE to be overridden by the data set labels or JCL, especially on systems with SDB. It may even mean that IEBGENER's SYSPRINT could be allocated to a *real* line printer without coding any DCB parameters in the JCL, and it would still work. (Haven't tried this one. g) (S013-34 is the usual abend for when BLKSIZE=0 persists, IIRC.) But it does mean that SDB at OPEN-time will never occur in this case. (I suppose the exit could be changed to check for a TAPE or DASD file, and leave BLKSIZE=0 if it is, but the business case for this may not be strong. IEBGENER, being part of DFP, knows that SDB is present. A 3rd party utility, designed for any MVS ever, would have to check that SDB is present. Hang on, that's another thread. Don't mention the PLO instruction. I mentioned it once, but think I got away with it.) In summary, SDB gets two opportunities to run: 1) during allocation, 2) during OPEN, but only for TAPE or DASD when DSORG is PS or PO. Cheers, Greg P. -- 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: PARM=
I'd like to cast a vote for JCL PARMs longer than 100 bytes, using the current scheme simply (?) by increasing the upper limit. I agree with protecting APF authorised programs from inadvertent parameter overrun. I don't think non-APF authorised programs need this protection, although I would expect IBM to check its IEB/IEH utilities, and other common programs like service aids for problems in this area. Assuming a program is expecting a parm length no more than 50, code like LH R2,0(,R1) CH R2,=H'50' BH PARMLONG will not trap a 40,000 byte parm, but the JCL deck size may be a bit of a giveaway, so no big deal IMHO. I think computers can count data bytes better than humans, so I liked someone's idea (much earlier in this thread) of a JCL info message reporting the PARM length for each step which has one. This may provide a very handy diagnostic for long PARMs. Further, I think this message should be issued no matter what the PARM length (ie. even for very short PARMs) whenever the system has long PARMs enabled, as an obvious flag to all that long PARMs are currently allowed by the system. (Dispense with the DISPLAY command, perhaps?) Cheers, Greg P. -- 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
