Re: Why CLOSE gets rc=4
Oh, the hazards of working without coding examples and manuals at hand! Obviously I've suffered a memory parity error and the peculiar failures in the past that I'm thinking of must have been from using CLOSE (R3) rather than CLOSE ((R3)), which I confirmed does indeed pass the contents of R3. Perhaps your failure is for the same reason that the system is getting what we like to call the "I've Gotcha" error on autoclose. The IEC999I basically says the system can't find a valid DCB where he thinks there ought to be one to CLOSE the open file at step termination. Have you by any chance freed the storage containing the DCB before you do the CLOSE? If the storage is still allocated and R3 still contains the correct address, then another possibility to consider is that your program has somehow overwritten the DCB with garbage. Steve Myers wrote: OPEN ((R3)) and CLOSE ((R3)) produce the same result. That part of the code is correct. Joel C. Ewing wrote: I have been burned in the past by the syntax for OPEN and CLOSE not being identical. You have an extra pair of parentheses in your CLOSE which I believe is causing the macro to interpret your DCB address as being an expression "(R3)" rather than a register reference, which would mean it would be looking at absolute location "3" rather than using the contents of register 3 as the DCB pointer. Needless to say it won't find a valid DCB there. I believe you want instead CLOSE (R3),MODE=31 In contexts where a DCB auto close at step termination succeeds, some programs may run with this kind of bug for years with no ill effects other than the mysterious error message from attempting to do a CLOSE on a bad DCB with a strange DDNAME. Your IFGOTCOA error indicates that auto-close is not succeeding, so there could be other undesirable side effects if the problem is not fixed. Paul Schuster wrote: Hello: I have a AMODE 31 RMODE ANY program that dynamically allocates an existing PDS with DISP=SHR and NDISP=KEEP. I create a DCB in 24bit storage, and issue OPEN like this: OPEN ((R3),INPUT),MODE=31 The OPEN completes RC=0. With very little intervening code (a WTO, but no READ of the data set) I issue this: CLOSE ((R3)),MODE=31 R3 does point to the DCB, but the CLOSE gets RC=4. I get messages like this: IEC223I 04,IFG0200V,INIT,,UNKNOWN IEC999I IFG0TC0A,IFG0TC0B,INIT ,,DEB ADDR = 7BDD94,DSN = thedsnthatwasopened Any idea on what is wrong? I don'tspecify a DCBE, as that is supposed to be optional?? Thank you. Paul ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: SEQUENCE NUMBERS
Ed Gould wrote: While your statement is true it would seem to me JES2 (JES3?) still sends out source and as long as it does then statement sequence numbers are needed. I vaguely remember that IBM at one time said they were going to stop sending out source for the JES's. They have done this with new function modules (at least JES2) I don't know if there is a specific date for the rest of the source. I believe this is planned for the year after the 64-bit TOD clock wraps. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- 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: SEQUENCE NUMBERS
John, While your statement is true it would seem to me JES2 (JES3?) still sends out source and as long as it does then statement sequence numbers are needed. I vaguely remember that IBM at one time said they were going to stop sending out source for the JES's. They have done this with new function modules (at least JES2) I don't know if there is a specific date for the rest of the source. Ed On Jul 29, 2006, at 8:21 PM, john gilmore wrote: Ted MacNeil WRITES: REPEAT AFTER ME! SMP is your friend! SMP NEEDS statement numbers. SMP certainly uses SNs and IEBUPDTE in some contexts. Equally, it omits to use them in others where it could do so. It never needs to use them, and it would be well if it had stopped doing so long ago. Affection for obsolete technology is understandable, even beguiling; but it is counter-productive. John Gilmore Ashland, MA 01721-1817 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/ direct/01/ -- 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 -- 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: SEQUENCE NUMBERS
Ted MacNeil WRITES: REPEAT AFTER ME! SMP is your friend! SMP NEEDS statement numbers. SMP certainly uses SNs and IEBUPDTE in some contexts. Equally, it omits to use them in others where it could do so. It never needs to use them, and it would be well if it had stopped doing so long ago. Affection for obsolete technology is understandable, even beguiling; but it is counter-productive. John Gilmore Ashland, MA 01721-1817 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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: SEQUENCE NUMBERS
>Their current uses are exiguous; they are of only antiquarian interest; and >even that interest has, it seems to me, been exhausted. REPEAT AFTER ME! SMP is your friend! SMP NEEDS statement numbers. When in doubt. PANIC!! -- 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: APF Authorized Code/Libraries.
On Fri, 28 Jul 2006 17:16:44 -0400 Wayne Driscoll <[EMAIL PROTECTED]> wrote: :>While that is true, since non-reentrent code loaded out of an APF :>authorized library is loaded into KEY 8 storage, there is an integrity :>exposure if said code is loaded into a multi-user address space, since :>it is open to being modified (by accident or by intent) by a :>non-authorized program. Since a reentrant program loaded from an APF :>authorized library is loaded into KEY 0 storage, only another authorized :>program could switch to PSW key 0 and modify the storage. That is among the minor worries of trying to directly execute APF code in a multiuser address space. Besides the program itself, there is the data areas and the save areas used by the program. Such code would be best served by being executed via SVC/PC or by stopping the other tasks in the address space (as done by TSO). -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- 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: Why CLOSE gets rc=4
I have been burned in the past by the syntax for OPEN and CLOSE not being identical. You have an extra pair of parentheses in your CLOSE which I believe is causing the macro to interpret your DCB address as being an expression "(R3)" rather than a register reference, which would mean it would be looking at absolute location "3" rather than using the contents of register 3 as the DCB pointer. Needless to say it won't find a valid DCB there. I believe you want instead CLOSE (R3),MODE=31 In contexts where a DCB auto close at step termination succeeds, some programs may run with this kind of bug for years with no ill effects other than the mysterious error message from attempting to do a CLOSE on a bad DCB with a strange DDNAME. Your IFGOTCOA error indicates that auto-close is not succeeding, so there could be other undesirable side effects if the problem is not fixed. Paul Schuster wrote: Hello: I have a AMODE 31 RMODE ANY program that dynamically allocates an existing PDS with DISP=SHR and NDISP=KEEP. I create a DCB in 24bit storage, and issue OPEN like this: OPEN ((R3),INPUT),MODE=31 The OPEN completes RC=0. With very little intervening code (a WTO, but no READ of the data set) I issue this: CLOSE ((R3)),MODE=31 R3 does point to the DCB, but the CLOSE gets RC=4. I get messages like this: IEC223I 04,IFG0200V,INIT,,UNKNOWN IEC999I IFG0TC0A,IFG0TC0B,INIT,,DEB ADDR = 7BDD94,DSN = thedsnthatwasopened Any idea on what is wrong? I don'tspecify a DCBE, as that is supposed to be optional?? Thank you. Paul ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: SEQUENCE NUMBERS
john gilmore wrote: SNs were useful when cataloged procedures and source programs were maintained using such batch edit utilities as IEBUPDTE and IEBUPDAT. Their current uses are exiguous; they are of only antiquarian interest; and even that interest has, it seems to me, been exhausted. That's an interesting statement; are there data to support your position that this is the case for most installations? I find sequence numbers to be handy when restricting searches, especially when using editors outside of SPF's. They can also be useful to detect omissions in CUT and PASTE operations, and they are extremely useful to disambiguate similar stretches of code. And I still use Cornell's IEBUPDTX to maintain versions of programs. Gerhard Postpischil Bradford, VT -- 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
New Mainframe Installations & Education
Several hours ago, I had entered a nice email on this topic that was running under the subject of: Re: IBM Redbook: "Introduction to the New Mainframe: z/OS Basics" . Since I spent about 10 minutes composing it, the *&*^% web site that I use to read IBM-Main on my laptop timed out. Usually, I can cut and paste the reply into a new email, but somehow I didn't get it cut, so when I tried to paste it into a new email, there was nothing there. That's our lousy Wisconsin Roadrunner webmail site. Sometimes, I think it times out in 5 minutes, and other times I swear it takes over a half hour. This email is from my desktop, using the usually reliable Outlook Express. I'll try to remember what I said before. I have a friend who is the Dean of the IT program at the Waukesha Community Technical College (WCTC). He also used to be the president of the WASM (Wisconsin Association of Systems Management), a Naspa group. He has pretty much the same thing to say about new programs, such as the mainframe training that IBM is trying to get more colleges to offer. He says there has to be a market for it. Unfortunately, in the greater Milwaukee area, that market is diminishing more each year. Obviously, as I have told you in the past, the MVS mainframe is no longer in P&H Mining Equipment, where I used to work. I know of 2 more mainframes going away in the area, one in September, and one I think in about a year, although it may be 2 years. (CRS). I estimate 10 to 12 mainframe data centers in the Milwaukee area at this time. When I started at P&H, I think there was more like 30 to 40. I know I had at least 10 interviews at companies in the area before I got my job at P&H. Now, there is only one job that I have heard of in the area for the last year and a half for a sysprog. Unfortunately I didn't get it. I go to a group at our church that meets monthly to encourage and help people who are out of work, or underemployed. The leader of the group, who has worked in personal in the area most of his life, made the comment that southeast Wisconsin is the graveyard of IBM mainframes. It was really interesting, because at that meeting, a friend of mine who I used to work with about 25 years ago who was also a sysprog, gave his testimony of how he was out of work for over a year, and then finally got back into work in mainframe computers. I think he now is an application programmer, but I don't know for sure. I do know that now he has to drive 50 or 60 miles one way to northern Illinois every day. By the way, I have a good lead on a job in Milwaukee, but as a Data Center Technical Analyst, not a sysprog. I would rather stay in Milwaukee doing that than make more money elsewhere as a sysprog. Someone made the comment recently that they thought there were more postings on job boards for sysprogs. I have noticed that also, since I apply for most of the jobs that I qualify for. I especially noticed more and more jobs being offered by headhunters on the job boards. I don't think there was a lot of IT placement by headhunters in our profession for a while. I talked to one recruiter who still is in business in Milwaukee, but they do none of the previous placement where they get 30% or so of the persons first year of salary. Now he does things like screening resumes for companies when their personel department is too busy. I think this email was a lot longer than my original, but then I didn't have to worry about my webmail site timing out. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee Wisconsin 414-475-7434 -- 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: wd4z JES job Monitor
Mary Kay Tubello wrote: I just installed wd4z 6.01. Having trouble starting the JES Jmonitor on the default port of 6715 on a zos 1.6 system. It works on a test 1.7 system. It starts ok if the port number is 3 digits, but not when it is 4 digits. Anyone have any ideas? Thanks, Mary Kay Do you get any errors? Could port 6715 be reserved on your 1.6 system? -- 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: SEQUENCE NUMBERS
In a message dated 7/29/2006 5:42:36 A.M. Central Standard Time, [EMAIL PROTECTED] writes: AFAIK the sequence numbers are completely useless nowadays. It was used for punched card sorter. Is there any other application ? >> Your PARMLIB and a few others are maintained by SMP/E with IEBUDTE via sequence numbers. Some of the vendors too, CA-1 comes to mind. -- 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
wd4z JES job Monitor
I just installed wd4z 6.01. Having trouble starting the JES Jmonitor on the default port of 6715 on a zos 1.6 system. It works on a test 1.7 system. It starts ok if the port number is 3 digits, but not when it is 4 digits. Anyone have any ideas? Thanks, Mary Kay -- 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: SEQUENCE NUMBERS
SNs were useful when cataloged procedures and source programs were maintained using such batch edit utilities as IEBUPDTE and IEBUPDAT. Their current uses are exiguous; they are of only antiquarian interest; and even that interest has, it seems to me, been exhausted. John Gilmore Ashland, MA 01721-1817 USA _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ -- 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
Sequence Numbers
> AFAIK the sequence numbers are completely useless nowadays. It was used > for punched card sorter. Is there any other application ? OK. Anyone who agree with the above statement is no longer allowed to use ++MACUPT or ++SRCUPD in SMP or to ever use IEBUPDTE. Granted, these are very special, somewhat limited use functions, but how many Systems Programmers would be happy to have IBM strip all of the sequence numbers from every Macro or Source member that they still distribute? Keith E. Moe Laid Back Software, Inc. http://www.laidbacksoftware.com (408) 749-0655 Creator of the TSO Environment and Administration Manager Product. Seeking employment and consulting opportunities with MVS. Located in Silicon Valley. Willing to Travel. Over 35 years in the industry (26 with one company). Resume: http://www.laidbacksoftware.com/resume.html Contact: [EMAIL PROTECTED] -- 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: SEQUENCE NUMBERS
In a recent note, R.S. said: > Date: Sat, 29 Jul 2006 12:42:19 +0200 > > > Perhaps you feel that all utilities, on all platforms, should > > process only columns 1-72 of their input data. Ain't gonna > > happen. > > Even some mainframe programs interpret it as data, with funny effects > somtimes. For example SYSIN DD * for FTP program cannot contain the > numbers. AFAIK some TCPIP config files as well. > ITYM "INPUT DD *". (Feels like Pascal, doesn't it?) Perhaps the access methods should strip off the sequence numbers so utilities and user programs need never be concerned with them. > AFAIK the sequence numbers are completely useless nowadays. It was used > for punched card sorter. Is there any other application ? > No longer. The 700/7000 series had a card reader (407 variant?) that read cards in row binary, two 36-bit words per row (software converted to BCD) , so there were always 8 columns you couldn't read. You could select which 8 with a plugboard. This likely contributed to the convention of 8-character sequence numbers. The PDP-6/10/20 stored 5 ASCII characters per 36-bit word (sometimes), so 5-character sequence numbers were conventional. It used bit 35 as a flag to indicate that the word contained a sequence number that the programmer might chose to ignore. -- gil -- StorageTek INFORMATION made POWERFUL -- 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: 2105 to 2107 Migration Question
When IBM migrated our DASD from 2105 to 2107 1st Q this year (on a 2064-106), FDRPAS is the tool they brought with them. CPU use by FDRPAS was not an issue - device activity and channel activity could be, especially if you have any specific devices that are already showing up as a performance bottleneck (and having a faster processor actually increases your exposure for DASD bottlenecks). Do you depend on PAV support for performance on the 2105? One of the limitations of FDRPAS 6 months ago was that it had to disable PAVs on the source and target DASD volumes while it was migrating it from 2105 to the 2107. If you did the migration on a "hot" device at a time when its workload required PAVs for acceptable performance, then applications could see significant response degradation on the device for several minutes, even if the DASD subsystems themselves had plenty of reserve capacity. If FDRPAS still has this limitation and you depend on PAVs, be forewarned and either chose slack periods for migrating critical high-activity devices or monitor response closely during the migration. We also did the migration without significant impact on the users. Howard Rifkind wrote: Hal, I just went thru this 2 weeks ago. Can you get your hands on FDRPAS? Worth every cent you pay for it. We used it in prime time on an MP300/H-50, which is much slower then the box you have. I did it in prime time and it was a piece of cake, no one even know I was doing it. Hal Merritt <[EMAIL PROTECTED]> wrote: We are on a countdown to move from a 2105-800 Shark to a 2107-921 DS8100. The motor is a z/890 2066-0A4. We are a 7x24 online shop with some tight SLA's. All of our slack for years was consumed by a generator failure. We have four FICON paths to the Shark and two to the DS8100. The thought is to swing one of the FICONs to the DS8100 making three each for the transition. The transition will be 'hot' using IBM services and the FDR product. Question: are the channels faster in the DS8100? Should we stay with the 4-2 split until after the migration is complete? Thoughts? Suggestions? Thanks all. ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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 set ENQueues and DEQueues in Jobs
On Friday 28 July 2006 23:47, Steve Myers wrote: >>> At step end, the initiator will DEQ any DSNs that are no longer >>> needed, i.e. those which are not referenced on a DD in any later >>> step. > This change was fairly recent. Originally, the data set ENQ lasted > for the life of the job. I do not recall when the data set ENQ was > released when the last step that referenced the data set in JCL > terminated. I don't think it was "fairly recent". In fact, I'm quite sure MVS has behaved like this since the beginning, over 30 years ago. The allocation routines keep a table in SWA called the DSNAME Table (DSNT) which contains an entry for each dsname in the job along with the 1-byte number of the last step that references it. At the end of each step, the table is scanned for matching step numbers and DEQs are issued accordingly. The SVA of the DSNT is in field SCTADSTB. The IEFDSNT macro describes the DSNT. The RECALL module in file 183 of the CBT tape scans the DSNT. I don't recall if DYNALLOC creates entries in the DSNT. My guess is that it doesn't, but I don't really know. -- Gilbert Saint-Flour GSF Software http://gsf-soft.com/ mailto:[EMAIL PROTECTED] -- 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: SEQUENCE NUMBERS
R.S. wrote: Paul Gilmartin wrote: In a recent note, "Shmuel Metz (Seymour J.)" said: Date: Fri, 28 Jul 2006 16:57:30 -0300 That said, others have told you about UNNUM; that will indeed delete those sequence numbers, which in fact are not annoying. It appeared to me that the OP, perhaps using ISPF as the editor- of-choice, was composing data to be exported as input to a desktop program. Many such programs treat all available columns as data, in which case those sequence numbers are, in fact, annoying. Perhaps you feel that all utilities, on all platforms, should process only columns 1-72 of their input data. Ain't gonna happen. Even some mainframe programs interpret it as data, with funny effects somtimes. For example SYSIN DD * for FTP program cannot contain the numbers. AFAIK some TCPIP config files as well. AFAIK the sequence numbers are completely useless nowadays. It was used for punched card sorter. Is there any other application ? Well, the last two digits are a level number, so you can tell which lines have changed at different levels. I don't care so much about that, but I can see that some people might. Kind regards, -Steve Comstock -- 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: HSA Estimate
>> These days, I would plan for a minimum of 1GB HSA, and a minimum of 3 per >> LPAR. >> More if it's doing real work (DB2, IMS, or CICS). >Wrong plans IMHO. HSA size strongly depends on CPC generation. Before >z/990 (that means 9672, z/900, z/800) HSA size was related to IODF size >- number of devices, number of LPARs. >On z/990 HSA size grew up significantly and took approx. 1GB. It's not a 'wrong' plan. It's a minimum. Most are still on a z/990 or smaller, so it's a good starting point. But, my point was: why worry about something as small as 128MB? Memory is cheap, and with today's memory-intensive workloads, it's cheaper than the paging overhead. When in doubt. PANIC!! -- 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: OSA SF and IOACMD
>Calm down, it is not worth to worry about. Actually, I was calm! It just seems that some people can't take a hint, so I raised the tone of my response. Schmeul, nobody wants to hear it! BTW, I'm taking the kill file route, too. So, respond if you like, I won't see it! When in doubt. PANIC!! -- 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: SEQUENCE NUMBERS
Paul Gilmartin wrote: In a recent note, "Shmuel Metz (Seymour J.)" said: Date: Fri, 28 Jul 2006 16:57:30 -0300 That said, others have told you about UNNUM; that will indeed delete those sequence numbers, which in fact are not annoying. It appeared to me that the OP, perhaps using ISPF as the editor- of-choice, was composing data to be exported as input to a desktop program. Many such programs treat all available columns as data, in which case those sequence numbers are, in fact, annoying. Perhaps you feel that all utilities, on all platforms, should process only columns 1-72 of their input data. Ain't gonna happen. Even some mainframe programs interpret it as data, with funny effects somtimes. For example SYSIN DD * for FTP program cannot contain the numbers. AFAIK some TCPIP config files as well. AFAIK the sequence numbers are completely useless nowadays. It was used for punched card sorter. Is there any other application ? -- Radoslaw Skorupka Lodz, Poland -- 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: IOCDS with VM and zOS LPARS
Marc Holiwell wrote: I am currently running two LPARs (with zOS 1.4 as OSes) on a IBM 2086 model A04(220), and would like to know if it is possible to create an IOCDS that will support an LPAR with VM as the OS, and another LPAR with zOS as the OS...??? As other already mentioned, LPAR definition is the same for z/OS and z/VM (the distinction is between OS nad CF). OS config contains distinction between MVS and VM type. However, especially when using Linux under VM, it is worth to mention how to "isolate" MVS devices from VM. It can be done via "Explicite device list" - at LPAR level, while z/OS is usually filtered at OS config level. First method is at IOS level, while OS config can be changed on operating system (and Linux does not honor it). My $0.02 -- Radoslaw Skorupka Lodz, Poland -- 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: HSA Estimate
Ted MacNEIL wrote: HSA is currently at 128mb. All main is allocated, no slop anywhere. If HSA grows, then I'll lose an LPAR. 128MB is nothing for HSA, these days. If you are so tight that an increase to such a small HSA is an issue, you have a bigger problem than the size of HSA! At $10K/GiB, what are you waiting for. These days, I would plan for a minimum of 1GB HSA, and a minimum of 3 per LPAR. More if it's doing real work (DB2, IMS, or CICS). Wrong plans IMHO. HSA size strongly depends on CPC generation. Before z/990 (that means 9672, z/900, z/800) HSA size was related to IODF size - number of devices, number of LPARs. On z/990 HSA size grew up significantly and took approx. 1GB. Relationship between IODF content and HSA size was greatly reduced. On z9 HSA grew up again, now it's approx. 1.9GB. I did some tests: minimal config (2 or 3 LPARs, 7000 devices, single CSS) took approx. 300MB less than "max. config" (18 LPARs, 2 CSSes max. # of devices each). YMMV, but the dependence on CPC model is unquestionable. BTW: minimum memory size on z9 (and z/990) is 16GB. Even with HSA of 2GB it's not bad to have 14GB for the beginning ! Regards -- Radoslaw Skorupka Lodz, Poland -- 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: OSA SF and IOACMD
Ted MacNEIL wrote: Did it ever occur to you that the same is true for using USS when you don't mean USS? Give it a rest! Even IBM calls it USS. The weight of the world must not be on your shoulders if you have nothing to worry about besides a silly anacronym. Ted, Calm down, it is not worth to worry about. Since I noticed that vast majority (or even all) of Shmuel's mails contains only "no, you're wrong" or "USS is not unix" I stopped responding him. I put his e-mail in kill-file, so his mails are filtered. That's good: no more badgering. I don't loose anything valuable, cause usually Shmuel's mails does not contain any help, rather malice and badgering instead. Soemtimes, when browsing archives through web interface (no filter on Shmuel) I read his mails - that convices me it was good decision to make a filter. Regards -- Radoslaw Skorupka Lodz, Poland -- 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: IBM Redbook: "Introduction to the New Mainframe: z/OS Basics"
On Sat, 2006-07-29 at 00:40 -0500, Bill Seubert wrote: > When we can connect customers who have > skill issues to the universities from which they hire students, ... Excuse my sceptocity, but such "customers" exist ??? >From my perspective, seems that customers are more willing to hire expertise than assist its growth. Whilst good for me and others with the requisite experience/expertise, it is a stone wall for those attempting to enter the industry. Bloody short sighted. Then there is the issue of off-shoring the whole kit and caboodle ... At one site we even spend almost two years training a customers employee as a sysprog. Only for said customer to decide they didn't see a future for their technical people in MVS, and they moved him elsewhere. Years later I still provide MVS services to this customer, and that trainee has left - but the training has been wasted as he now does "toy-box" support. Good luck, but I empathise with the earlier comment about turning (such) a big boat. Shane ... -- 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: SEQUENCE NUMBERS
Hello John, I have been reading my digest copy of yesterday's posts and found a bunch of similar replies. I will not assume that you can actually access ISPF EDIT on your mainframe. If you do and you edit the JCL you most likely wont know that in columns 73- 80 there may be line numbers. The editor will put them there if your edit session has NUM(ON) set in the current edit profile (ref PROFILE primary EDIT command). If you cannot see them you may need to scroll your edit session "RIGHT" to see these columns. So all the posts I have read so far assume you can edit these JCL files in ISPF. Please confirm that the numbers you are seeingt are 8 digit numbers in columns 73-80. If they are not then something else may be generating them. On Fri, 28 Jul 2006 22:11:55 +1000, John Dawes <[EMAIL PROTECTED]> wrote: >I noticed that when I perform a FTP function from Mainframe (I am using FTP to retrieve jcls) to my pc I notice that sequence numbers appear on the file. > > How can I prevent these annoying sequence numbers from appearing on the output? > > Thanks > Regards Bruce Hewson -- 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
