Issues while trying to install COD
Hi All, I'm trying to install COD in our machine. As per the COD installation guide, I have mounted the stand-alone tape in the tape drive and performed the LOAD process. Also i'm able to perform the initial steps (ie) using ICKDSF program to perform the initialization of volumes. The next stop is to restore the COD tape contents into the dasd volumes initialized. As per the guide, it should invoke the DFSMSdss program which is located as 3rd file in the tape. So i tried the LOAD process once again to invoke the DFSMSdss program. But it is again showing me the ICKDSF step only. So please suggest me how do i read the DFSMSdss program to restore COD tape contents. Please let me know if you need any other details. I'm using HMC, "Operating system messages" panel to perform these steps. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
Thanks Kirk for the pointer to the doc and others for pointing out the unavoidable complexing situations. One question to possibly avoid the problem of where to write the files with all their considerations: we have a Syslog Deamon running, can I have the messages sent to this place? That would be quite helpful. Kees. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kirk Wolf Sent: Tuesday, May 13, 2014 17:39 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? often the answer is "nowhere". See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, May 13, 2014 at 6:32 AM, Vernooij, CP (SPLXM) - KLM < kees.verno...@klm.com> wrote: > Hello group, > > We have some dataset problems with USS processes and are looking for > the allocation messages. > I mean the > IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) > DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) > STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () > VOL SER NOS= VIO > and similar that you see in the message file of a job or STC or even > in Syslog for an STC under MSTR. > > Where do these and other messages going for a USS process? > A BPXAS STC is started for the process, but this only contains the > messages for the BPXAS itself. > > Thanks, > Kees. > > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. > If you are not the addressee, you are notified that no part of the > e-mail or any attachment may be disclosed, copied or distributed, and > that any other action related to this e-mail or attachment is strictly > prohibited, and may be unlawful. If you have received this e-mail by > error, please notify the sender immediately by return e-mail, and delete this > message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or > its employees shall not be liable for the incorrect or incomplete > transmission of this e-mail or any attachments, nor responsible for any delay > in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal > Dutch > Airlines) is registered in Amstelveen, The Netherlands, with > registered number 33014286 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Skip: Our IBM SE (30+ years ago) wrote an orange manual (how many remember those?), About blocksize and tape. It pretty much said that use of a 32K blocksize as optimum for channel and tape utilization (this was 6250 BPI IIRC). Jim (our SE has retired) after serving time at the WSC and out in San Jose. But through the years the best thruput as to always code 32K for job where performance is needed. Of course with new technology I expect that the device that can handle 256K blocksize be used. I have often disliked the DFDSS manuals for not being straight forward in their documentation. I don't think DFSMS does the right thing with blksize=0 for tape, my memory is obsolete here but it used to be 16K when blocksize eq zero is used. Ed On May 13, 2014, at 6:25 PM, Skip Robinson wrote: We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easy demonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program that uses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code >32K block size in JCL for a program with DCB, the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable >32K block size. Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: "If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760." So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster with the maximum block size than with a smaller one. (I did not test DFDSS per se.) But as already indicated, the inhibitor to stellar performance may be on the input side, over which you have little control. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ron Hawkins To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/13/2014 09:15 AM Subject:Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Sent by:IBM Mainframe Discussion List m...@listserv.ua.edu> Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. From your questions you are focusing on the tape output rate as the gating factor for the elapsed time of the dump, but have you looked at the time spent processing the input files? I may be having a senior moment, but there are two things that may be affecting the performance of the PS-E data set. (1) I seem to recall that DFSMSdss will process a compressed PS-E data set at block level and not attempt to compress it in order to avoid double compression overhead when COMPRESS is specified, and (2) compressed PS-E data sets do not chain more than one track of at a time. I'll leave it to you to hit the manuals and see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: Monday, May 12, 2014 7:11 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Victor, The blksize is not the only way to tune a process for efficiency. And in some cases, there is little you can do to affect some applications like DFDSS. If you are using the hardware for tape is virtual tape of oracle, vsm5. Then there may be nothing more you can do. So
Re: Buying desktop software from IBM
How odd that they didn't include the "real" one - Canadian English EH!! John T. Abell President International Software Products Tel: 800-295-7608 Ext: 224 International: 1-416-593-5578 Ext: 224 Fax: 800-295-7609 International: 1-416-593-5579 E-mail: john.ab...@intnlsoftwareproducts.com Web: www.ispinfo.com This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, retention, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive on behalf of the named recipient), please contact the sender by reply email and delete all copies of this message. Also,email is susceptible to data corruption, interception, tampering, unauthorized amendment and viruses. We only send and receive emails on the basis that we are not liable for any such corruption, interception, tampering, amendment or viruses or any consequence thereof. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Tuesday, May 13, 2014 6:23 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Buying desktop software from IBM In the checkout process, it wants to know my "Communication Language" and my "Media Language". For the latter, choices include: Australian English British English Eastern European English English International English US English I'd be hard-pressed to choose among several of those.or to even imagine what Eastern European English is?! Anyone? Bueller? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Good News: Introducing Mobile Workload Pricing (MWP) for z/OS
MRWT is expected to be available next month (June). In the meantime, it's probably not worth speculating too much. As informed speculation, the MWRT path isn't going to be much different from the SCRT path given that MWRT is announced as a perfect superset. Thus I would predict it's pretty much business as usual for those of you already working with SCRT. As always, if you have concerns about the tool, let IBM know through official channels. With respect to the Microsoft Windows requirement, I must have been thinking of the spreadsheet method of viewing and editing an SCRT report. And that's optional, correct. (And it doesn't require Microsoft Windows as it happens.) That may be what the MWP announcement letter was referring to (awkwardly or even incorrectly perhaps), but we'll soon find out. Timothy Sipples IT Architect Executive, zEnterprise Industry Solutions, AP/GCG/MEA E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
You might see if the WRITE Statements in the ACS code might be helpful. It can produce statements to SYSLOG in any format with the vars available to SMS. So you could have IF JOBNAME = "BPXAS" Then DO WRITE END Or something similar. DSN, VOLUME, UNIT, USER, and a few other might be used to do the IF THEN test with. The write statements should go into the task or SYSLOG, but as always, it depends. I have not tested with USS address spaces, but it might work. Lizette > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Tony Harminc > Sent: Tuesday, May 13, 2014 5:22 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Where are the allocation messages of a USS process? > > On 13 May 2014 17:58, Jon Perryman wrote: > > As Tony said, they are all WTO messages. JES decides where it wants to put > > the > message (or not do anything with it). > > Well I'm not so sure they're all WTOs. I think there's a PUT (likely > RPL-type) interface to the JESYSMSG dataset that allocation writes to, and > that > those WTOs that do appear there are copied in by some piece of WTO/WTP > processing that issues the PUT. In other words the JESYSMSG is primary, and > WTOs are just one thing that can be written there. I doubt that JESn captures > such > messages only through the SSI, though they would presumably go there too. But > I'm > not current on JES2/3 or allocation/conversion/interpretation. > > > As for capturing messages USS mesages placing them into the appropriate job, > this may be more than you expect. > > I've given it some thought over some years. But yes, there are difficulties. > > > Some of the problems would be: > > 1. Which parent/grandparent should receive the messages? > > The parent process for a process is well defined, though the parent may no > longer > exist. I think the algorithm would be to work up the ahnentafel until the > first process > with a job log is found. It might be as simple as the first process whose > parent is 1. > But even if it's more subtle, I don't think it's very difficult. > > More tricky is to avoid having two copies of all such messages in the SYSLOG. > > > 2. Will the messages truly be helpful since it will be more difficult to > > associate > messages to issuing process. > > I would insert a prefix containing the process and perhaps even thread ID. > Since > both IDs can be large, there would be some trouble with line length and > wrapping, > and even more with multi-line WTOs, but it could be done. > > > 3. BPXAS can be reused once the processes have terminated. In a busy UNIX > environment, this could either amount to a large number of messages for many > different processes that may or may not be related. > > The initiator is reused, but not the process ID, at least while it has > offspring. IBM has > this problem too and must deal with it; what if a process asks the kernel for > its > parent PID via getppid() and then tries to send it a message or something? I > don't > know the general UNIX semantics, but it surely wouldn't be acceptable for the > message to go to some unrelated process that happened to get the same PID. > > IBM's scheme seems to have been to split notional 32-bit PIDs into two 16-bit > pieces; the left half in some sense qualifies the right. If you issue a D > OMVS,A=ALL > and convert some of those huge PIDs to hex, you can easily see the split, and > that > the actual process IDs are quite small numbers. This suggests a limit of 64K > active > processes, which seems rather small in today's world. > > > Maybe a better alternative would be to use BPX_SHAREAS to share the > > address space with related processes > > Sure - if it can be done it's probably better all round, and cheaper. > But UNIX semantics in some cases require a new address space. > > > but it still leaves the problem where address space reuse with > > unrelated processes. I'm not trying to discourage you in doing. Just trying > > to make > sure you know about some of the hurdles. > > Thanks. > > Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On 13 May 2014 17:58, Jon Perryman wrote: > As Tony said, they are all WTO messages. JES decides where it wants to put > the message (or not do anything with it). Well I'm not so sure they're all WTOs. I think there's a PUT (likely RPL-type) interface to the JESYSMSG dataset that allocation writes to, and that those WTOs that do appear there are copied in by some piece of WTO/WTP processing that issues the PUT. In other words the JESYSMSG is primary, and WTOs are just one thing that can be written there. I doubt that JESn captures such messages only through the SSI, though they would presumably go there too. But I'm not current on JES2/3 or allocation/conversion/interpretation. > As for capturing messages USS mesages placing them into the appropriate job, > this may be more than you expect. I've given it some thought over some years. But yes, there are difficulties. > Some of the problems would be: > 1. Which parent/grandparent should receive the messages? The parent process for a process is well defined, though the parent may no longer exist. I think the algorithm would be to work up the ahnentafel until the first process with a job log is found. It might be as simple as the first process whose parent is 1. But even if it's more subtle, I don't think it's very difficult. More tricky is to avoid having two copies of all such messages in the SYSLOG. > 2. Will the messages truly be helpful since it will be more difficult to > associate messages to issuing process. I would insert a prefix containing the process and perhaps even thread ID. Since both IDs can be large, there would be some trouble with line length and wrapping, and even more with multi-line WTOs, but it could be done. > 3. BPXAS can be reused once the processes have terminated. In a busy UNIX > environment, this could either amount to a large number of messages for many > different processes that may or may not be related. The initiator is reused, but not the process ID, at least while it has offspring. IBM has this problem too and must deal with it; what if a process asks the kernel for its parent PID via getppid() and then tries to send it a message or something? I don't know the general UNIX semantics, but it surely wouldn't be acceptable for the message to go to some unrelated process that happened to get the same PID. IBM's scheme seems to have been to split notional 32-bit PIDs into two 16-bit pieces; the left half in some sense qualifies the right. If you issue a D OMVS,A=ALL and convert some of those huge PIDs to hex, you can easily see the split, and that the actual process IDs are quite small numbers. This suggests a limit of 64K active processes, which seems rather small in today's world. > Maybe a better alternative would be to use BPX_SHAREAS to share the address > space with related processes Sure - if it can be done it's probably better all round, and cheaper. But UNIX semantics in some cases require a new address space. > but it still leaves the problem where address space reuse with unrelated > processes. I'm not trying to discourage you > in doing. Just trying to make sure you know about some of the hurdles. Thanks. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
We had some issues a while back with VSM performance. I did research and experiments with various block sizes for tape data sets. Questions on IBM-MAIN and doc reading yielded some answers--though not necessarily solutions. -- Tape output is generally faster with larger block sizes. That's easy demonstrate by coding ever larger block sizes. EXCP count and elapsed time will both decrease. -- You can't just increase output block size willy-nilly. A program that uses a traditional DCB is limited to 32K bytes per block. To exceed that value, a program must employ DCBE, which is not hard to use but requires coding changes. -- If you attempt to code >32K block size in JCL for a program with DCB, the value will be ignored and revert to 32K. You might miss that fact because there's no message. Your tape management product (CA-1, RMM, etc.) will show you the actual block size of a file. -- Some IBM utilities are coded with DCBE to enable >32K block size. Others are not. Doc for each utility should indicate the maximum allowable output block size. -- DFSMSdss Storage Administration has this to say: "If the DCB keyword BLKSIZE is specified on the DD statement for tape, it must be in the range of 7,892 through 262,144. If the DCB keyword BLKSIZE is specified on the DD statement for DASD, it must be in the range of 7,892 through 32,760." So DFDSS uses DCBE and can write 256K blocks. In my testing, a job ran quite a bit faster with the maximum block size than with a smaller one. (I did not test DFDSS per se.) But as already indicated, the inhibitor to stellar performance may be on the input side, over which you have little control. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Ron Hawkins To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/13/2014 09:15 AM Subject:Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size) Sent by:IBM Mainframe Discussion List Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. >From your questions you are focusing on the tape output rate as the gating factor for the elapsed time of the dump, but have you looked at the time spent processing the input files? I may be having a senior moment, but there are two things that may be affecting the performance of the PS-E data set. (1) I seem to recall that DFSMSdss will process a compressed PS-E data set at block level and not attempt to compress it in order to avoid double compression overhead when COMPRESS is specified, and (2) compressed PS-E data sets do not chain more than one track of at a time. I'll leave it to you to hit the manuals and see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Monday, May 12, 2014 7:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives > VSM5 ( was Change tape block size) > > Victor, > > > The blksize is not the only way to tune a process for efficiency. And in some > cases, there is little you can do to affect some applications like DFDSS. > > If you are using the hardware for tape is virtual tape of oracle, vsm5. Then > there may be nothing more you can do. Sometimes the hardware controls > the process. > > I would open an issue with STK and ask them to assist you with this > configuration. There may be a parm or function unique to STK that may help > you. > > I might also open an SR/ETR with IBM DFDSS to see if they have any > suggestions. > > Lizette > > PS I changed the subject to for more visibility > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Victor Zhang > > Sent: Sunday, May 11, 2014 11:44 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Change tape block size > > > > Hello, > > First I need thank you who replied to my question. > > I should introduce my problem's background and my concern. > > The tape is virutal tape of oralce, vsm5. > > I am backing up extended format PS dataset
Re: Buying desktop software from IBM
On Tue, 13 May 2014 15:50:02 -0700, Skip Robinson wrote: >This list is fascinating both for inclusions and for omissions. I will >defer humbly to Radoslaw for opinion on 'Eastern European English', but I >lived five years in West Africa. While Nigeria and Ghana, for example, >sound pretty similar, the English of Liberia is a horse of a very >different color. We could add to the list a number of countries like India >where English is an official 'national language' or simply a de facto >lingua franca. > >And what pray tell is 'International English' or just plain old >unqualified 'English'? How many dictionaries do we have to keep at arm's >reach? > They're at risk of being called bigoted if they don't provide Ebonics. (But do they?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On Tue, 13 May 2014 14:58:01 -0700, Jon Perryman wrote: >As Tony said, they are all WTO messages. JES decides where it wants to put the >message (or not do anything with it). >I suspect that some WTO messages are never written in USS as opposed to not >being captured. I suspect that IBM disabled them for a reason.UNIX does so >much allocation that it could easily flood the SSI (WTO's). I can image that >issuing a make command would produce ton's of alloc / dealloc. > Indeed. Lately I did a "cp" of a couple hundred-member PDSE to a UNIX directory. Merely on elapsed time I can suspect that for each member it was doing ALLOCATE; OPEN; copy; CLOSE; FREE. (And catalog search?) >As for capturing messages USS mesages placing them into the appropriate job, >this may be more than you expect. Some of the problems would be: >1. Which parent/grandparent should receive the messages? >2. Will the messages truly be helpful since it will be more difficult to >associate messages to issuing process. >3. BPXAS can be reused once the processes have terminated. In a busy UNIX >environment, this could either amount to a large number of messages for many >different processes that may or may not be related. > This could be a problem with any child process that writes to a descriptor inherited from a parent process. AFAIK, it has been solved; perhaps as simply as by not reusing the address space until all such descriptors are closed. >Maybe a better alternative would be to use BPX_SHAREAS to share the address >space with related processes but it still leaves the problem where address >space reuse with unrelated processes. I'm not trying to discourage you in >doing. Just trying to make sure you know about some of the hurdles. > Writing such messages to a suitably propagated descriptor might be an effective alternative to S/360-think which appears to be the current approach. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another C compiler shift bug?
On Tue, 13 May 2014 17:47:39 -0400, Tony Harminc wrote: >On 8 May 2014 19:34, Farley, Peter x23353 wrote: >> ST doesn't accept a 3-modifier expression, that is an artifact of the XL >> C/C++ "assembler" listing format. > >This is really really annoying, and has been for years. The compiler >is now quite capable of producing correct assembler output when the >Metal option is specified, but presumably someone at IBM believes this >stuff is more readable, somehow. > >Maybe there's a requirement here. > One can argue that a couple ways: o The correctness of the assembler output could be verified by assembling it (possibly after filtering page headers, etc.). o False assembler output discourages users' tweaking it and using it in place of making modifications to the C source (and then reporting problems in the incorrectly tweaked code). Similar applies to the pseudo "JCL" produced by the "cc" (whatever) command, some of which is a circumvention of the 100-character PARM or 256-character pathname limit. Maybe it should emit Rexx instead of JCL. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Buying desktop software from IBM
This list is fascinating both for inclusions and for omissions. I will defer humbly to Radoslaw for opinion on 'Eastern European English', but I lived five years in West Africa. While Nigeria and Ghana, for example, sound pretty similar, the English of Liberia is a horse of a very different color. We could add to the list a number of countries like India where English is an official 'national language' or simply a de facto lingua franca. And what pray tell is 'International English' or just plain old unqualified 'English'? How many dictionaries do we have to keep at arm's reach? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Phil Smith III To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/13/2014 03:23 PM Subject:Buying desktop software from IBM Sent by:IBM Mainframe Discussion List In the checkout process, it wants to know my "Communication Language" and my "Media Language". For the latter, choices include: Australian English British English Eastern European English English International English US English I'd be hard-pressed to choose among several of those.or to even imagine what Eastern European English is?! Anyone? Bueller? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Buying desktop software from IBM
In the checkout process, it wants to know my "Communication Language" and my "Media Language". For the latter, choices include: Australian English British English Eastern European English English International English US English I'd be hard-pressed to choose among several of those.or to even imagine what Eastern European English is?! Anyone? Bueller? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
As Tony said, they are all WTO messages. JES decides where it wants to put the message (or not do anything with it). I suspect that some WTO messages are never written in USS as opposed to not being captured. I suspect that IBM disabled them for a reason.UNIX does so much allocation that it could easily flood the SSI (WTO's). I can image that issuing a make command would produce ton's of alloc / dealloc. As for capturing messages USS mesages placing them into the appropriate job, this may be more than you expect. Some of the problems would be: 1. Which parent/grandparent should receive the messages? 2. Will the messages truly be helpful since it will be more difficult to associate messages to issuing process. 3. BPXAS can be reused once the processes have terminated. In a busy UNIX environment, this could either amount to a large number of messages for many different processes that may or may not be related. Maybe a better alternative would be to use BPX_SHAREAS to share the address space with related processes but it still leaves the problem where address space reuse with unrelated processes. I'm not trying to discourage you in doing. Just trying to make sure you know about some of the hurdles. Jon Perryman On Tuesday, May 13, 2014 11:18 AM, "Farley, Peter x23353" wrote: Oops. You are absolutely correct, I got the names backwards. > >So what it putatively says is that allocation and initiation/termination >messages are captured, but WTO's and other "console" messages are NOT captured? > >Weird. > >-Original Message- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Tony Harminc >Sent: Tuesday, May 13, 2014 1:02 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Where are the allocation messages of a USS process? > >On 13 May 2014 12:08, Farley, Peter x23353 wrote: >> Perhaps because (at that link which Kirk posted) there is this note: >> >> "Messages that would normally go to the JESYSMSG data set are captured, but >> messages that go to JESMSGLG are not captured." >> >> Allocation messages go to JESMSGLG, and so it would seem are not captured. >> One wonders which bit-bucket they disappear into. > >I think this is backwards, at least if using the SDSF terminology. >What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), >while JESMSGLOG is the JESn-captured extract of WTOs written to the >system SYSLOG. JESYSMSG also contains *some* application program WTOs, >but I haven't put the effort into figuring out which ones. Maybe it's >as simple as those with ROUTCDE 11. > >I've thought about a WTO exit of one sort or another that would >capture WTOs from BPXAS processes, and write them to the JES log of >their parent process. Of course the parent may have gone away, and >there are various other problems, but it should be doable. At least >they are already available in the system-wide SYSLOG, but things like >allocation messages do indeed seem to go into a bit-bucket. > >Tony H. >-- > > >This message and any attachments are intended only for the use of the >addressee and may contain information that is privileged and confidential. If >the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. > > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another C compiler shift bug?
On 8 May 2014 19:34, Farley, Peter x23353 wrote: > ST doesn't accept a 3-modifier expression, that is an artifact of the XL > C/C++ "assembler" listing format. This is really really annoying, and has been for years. The compiler is now quite capable of producing correct assembler output when the Metal option is specified, but presumably someone at IBM believes this stuff is more readable, somehow. Maybe there's a requirement here. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Another C compiler shift bug?
For those concerned with the sub-optimal code generated by the compiler in my examples: FWIW, with OPT(2) unsigned long long maxBit = 0x1ull << (arraySize-3); compiles to LGHI r3,H'1' ... LGR r14,r1 ... AHI r14,H'-3' SLLG r14,r3,0(r14) STG r14,#SPILL9(,r13,360) The loading of R1 is complex. It loads R1 as well as R14 with arraySize because it needs it for something else a couple of instructions later. It took me about ten minutes to find the instructions in question. Optimized object code has nothing resembling a line-by-line relationship with the source code. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, May 08, 2014 4:01 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Another C compiler shift bug? On Thu, 8 May 2014 15:35:39 -0700, Charles Mills wrote: >Hmmm. Well, I beat the compiler into submission ... > "beat"? Actually I believe you lulled it into submission. >... > SLDL r2,0(r1) > LR r0,r3 > LR r1,r2 > ST r1,maxBit(,r13,248) > ST r0,maxBit(,r13,252) > Would there be anything wrong with: STM r2,r3,maxBit+248(r13) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: SCLM
Redbooks and SHARE are good learning experiences. I've got SG247392 penciled in for Redbooks and if you want more modern, this Boston SHARE on SCLM to RDZ conversion is a good starting place. https://share.confex.com/share/121/webprogram/Session13687.html Both have 'further reading' sections to aid the enablement. In a message dated 5/12/2014 2:39:29 P.M. Central Daylight Time, stars...@mindspring.com writes: If you have not done so, you might want to join the ISPF List -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
John, So what you call setting a token, IEANTCR ..then allocating storage based on the return address ? A block of storage ? Curious ... Scott ford www.identityforge.com from my IPAD > On May 13, 2014, at 1:32 PM, John Gilmore wrote: > > Some comments. > > The terms 'local' and 'global' have well-established definitions and > uses---They specify the scopes of set symbols at assembly time---in > the HLASM macro language, and their usurpation for other purposes is > ill-advised. '...that way madness lies; let me shun that; No more of > that'. > > Moreover, persistence and scope are very different notions. They are > sometimes hard to disentangle; but it is always unwise to confound > them. > > Persistence can be characterized in two ways, in terms of maximal > lifetime and dynamism. > > The obvious maximal lifetimes are termination by > o z/OS shutdown/IPL, > o jobstep, > o task, and > o block or routine exit > > It may or may not be possible to allocate and free a block of storage > dynamically. > > Thus, for example, the automatic/scratch storage of PL/I and then C is > allocated when control for a dispatchable unit enters a routine or > block and freed when it exits from that routine or block. It cannot, > that is, be allocated sooner or freed later. > > Automatic storage is also LIFO, stack-based storage, allocated from a > stack and freed/returned to that stack for reuse. Typically, pools > are also stacks, not because FIFO democracy is important for them but > because stacks are the easiest constructs to use to manage > interchangeable, reusable blocks of storage. > > Most other storage is non-LIFO, and a block of it is typically called > a heap. There are management issues for heaps, but most modern > operating systems handle them efficiently. Once allocated from a > heap, storage within such a block of can of course be > suballocated/managed as a stack or pool. > > The questions how best to manage heaps and where to put them do not > have any generic answers, but the lawyers' de minimis principle is > important for them. A system may usefully contain many stacks, but it > shouild not usually contain more than a very few heaps. > > Accesses to heaps must [almost] always be serialized; and adult, > asynchronous systems cannot be built without using serialization > machinery. > > Satisfactory systems can be written primarily in some statement-level > procedural language (SLPL), but routines written in that SLPL must > typically be supplemented by others written in assembly language. The > Scots poet Blair described archangelic visits to the earth, necessary > to keep things in order here below, as 'short and far between'; and > these assembly-language routines can have these two characteristics > too. They are, however, necessary 1) to close gaps in the SLPL being > used, 2) to avoid really ugly, infelicitous constructs in that SLPL, > and to circumvent serious inefficiencies in that SLPL's > implementation. For these reasons programmers who do not write > assembly language with facility are all but useless. The routines > they write always reflect the more or less radical imperfections of > the SLPL they use. > > John Gilmore, Ashland, MA 01721 - USA > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS FTPS Client & Linux FTP server
I'm delayed by the daily digest but did anyone mention the BpxMText suggested Action? To me, it indicates the solution might rely on the other end. TSO BPXMTEXT 77B17343 TCPIP JrTtlsClearTxtReceived: AT-TLS received clear text data when secure data was expected. Action: Enable the remote application for secure connections. Retry the connection. ps. *definitely* a n00b for both tcp/ip & at-tls and probably not helping any. > signature = 6 lines follows < Neil Duffee, Joe Sysprog, uOttawa, Ottawa, Ont, Canada telephone:1 613 562 5800 x4585 fax:1 613 562 5161 mailto:NDuffee of uOttawa.ca http:/ /aix1.uOttawa.ca/ ~nduffee “How *do* you plan for something like that?” Guardian Bob, Reboot “For every action, there is an equal and opposite criticism.” “Systems Programming: Guilty, until proven innocent” John Norgauer 2004 -Original Message- From: Mark Pace [mailto:pacemainl...@gmail.com] Sent: May 12, 2014 14:42 Subject: Re: z/OS FTPS Client & Linux FTP server EZA1554I Connecting to: 10.6.0.10 port: 21. [snip] EDC8121I Connection reset. (errno2=0x77B17343) EZA2897I Authentication negotiation failed EZA1534I *** Control connection with 10.6.0.10 dies. If I read this right the 7343 part of the errno2 says that it expected a secure response, but it was sent clear text. I've tried SECUREIMPLICITZOS both TRUE and FALSE - with true I don't see the 220- messages, but still get the same error. [snip] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
Oops. You are absolutely correct, I got the names backwards. So what it putatively says is that allocation and initiation/termination messages are captured, but WTO's and other "console" messages are NOT captured? Weird. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, May 13, 2014 1:02 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? On 13 May 2014 12:08, Farley, Peter x23353 wrote: > Perhaps because (at that link which Kirk posted) there is this note: > > "Messages that would normally go to the JESYSMSG data set are captured, but > messages that go to JESMSGLG are not captured." > > Allocation messages go to JESMSGLG, and so it would seem are not captured. > One wonders which bit-bucket they disappear into. I think this is backwards, at least if using the SDSF terminology. What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), while JESMSGLOG is the JESn-captured extract of WTOs written to the system SYSLOG. JESYSMSG also contains *some* application program WTOs, but I haven't put the effort into figuring out which ones. Maybe it's as simple as those with ROUTCDE 11. I've thought about a WTO exit of one sort or another that would capture WTOs from BPXAS processes, and write them to the JES log of their parent process. Of course the parent may have gone away, and there are various other problems, but it should be doable. At least they are already available in the system-wide SYSLOG, but things like allocation messages do indeed seem to go into a bit-bucket. Tony H. -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
W dniu 2014-05-13 19:24, willie bunter pisze: Good Day Members, I am trying to delete the VSAM components - data and index - from a disk volume. The problem is that there is a CLUSTER along with the same DATA & INDEX component names which reside on another voume. Is there a way deleting the errant components? Both volumes are SMS managed. If you don't feel comfortable: 1. Make a backup of the dataset, I mean the "proper" one. Use REPRO. Watch the messages and RC. 2. Just rename the proper dataset, that means rename cluster and both components names. Why? New names cannot be messed with orphaned component names. Now your data is safe. You can start main job. 3. Make sure those components are really orphaned, issue listcat. 4. Use DEL ...VVR, as Dennis suggested HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
Why don't you tell us what you tried and what happened. Show the exact commands and error messages. :>: -Original Message- :>: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>: Behalf Of willie bunter :>: Sent: Tuesday, May 13, 2014 10:24 AM :>: To: IBM-MAIN@LISTSERV.UA.EDU :>: Subject: DELETE VSAM COMPONENTS :>: :>: Good Day Members, :>: :>: I am trying to delete the VSAM components - data and index - from a disk :>: volume. The problem is that there is a CLUSTER along with the same DATA :>: & INDEX component names which reside on another voume. Is there a way :>: deleting the errant components? Both volumes are SMS managed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
Willie, Had the same problem this past weekend. The ones I wanted deleted were not cataloged. Here is the job that worked for me. Hope it helps you as well. //STEP1 EXEC PGM=IDCAMS //DD1 DDVOL=SER=WSC001,UNIT=3390,DISP=OLD //SYSPRINT DDSYSOUT=* //SYSIN DD * DELETE NETVIEW.TME54.SUR01.DSITRCS.DATA FILE(DD1) VVR - CAT(CATALOG.WSC.MASTER) -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of willie bunter Sent: Tuesday, May 13, 2014 12:24 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DELETE VSAM COMPONENTS Good Day Members, I am trying to delete the VSAM components - data and index - from a disk volume. The problem is that there is a CLUSTER along with the same DATA & INDEX component names which reside on another voume. Is there a way deleting the errant components? Both volumes are SMS managed. Thanks in advance for your help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN NOTICE: This e-mail message, including any attachments and appended messages, is for the sole use of the intended recipients and may contain confidential and legally privileged information. If you are not the intended recipient, any review, dissemination, distribution, copying, storage or other use of all or any portion of this message is strictly prohibited. If you received this message in error, please immediately notify the sender by reply e-mail and delete this message in its entirety. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DELETE VSAM COMPONENTS
I have seen where an ALTER NAME was done but the user forgot the DATA and
INDEX components. So the CLUSTER was the new name but the DATA and INDEX
were still the old name.
If you have a product like FILEAID or VANTAGE, you might be able to see if
that was done.
Just some questions.
Is the catalog shared or unique?
Are the datasets on different volumes - is one cataloged and the other not
cataloged?
Are you sure the one on the other volumes are not used?
Do a LISTC ENT('myvsamfile') ALL
Review the list of volsers it is on. Make sure you have a unique
uncataloged VSAM dataset.
If everything is good, then move all the good datasets off of the volume to
another volume - leaving the VSAM Data/Index where it is.
Then just init the volume. If it is not cataloged, then you will be safe.
I would go into ISPF 3.4 and put in the VSAM file and VOLSER in the panel.
Then when you bring it up, to a LISTC ENT(/) ALL and see if maybe there is a
mismatch between some other cluster and that DATA/INDEX
Lizette
> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of willie bunter
> Sent: Tuesday, May 13, 2014 10:24 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: DELETE VSAM COMPONENTS
>
> Good Day Members,
>
> I am trying to delete the VSAM components - data and index - from a disk
volume.
> The problem is that there is a CLUSTER along with the same DATA & INDEX
> component names which reside on another voume. Is there a way deleting
the
> errant components? Both volumes are SMS managed.
>
> Thanks in advance for your help.
>
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
Some comments. The terms 'local' and 'global' have well-established definitions and uses---They specify the scopes of set symbols at assembly time---in the HLASM macro language, and their usurpation for other purposes is ill-advised. '...that way madness lies; let me shun that; No more of that'. Moreover, persistence and scope are very different notions. They are sometimes hard to disentangle; but it is always unwise to confound them. Persistence can be characterized in two ways, in terms of maximal lifetime and dynamism. The obvious maximal lifetimes are termination by o z/OS shutdown/IPL, o jobstep, o task, and o block or routine exit It may or may not be possible to allocate and free a block of storage dynamically. Thus, for example, the automatic/scratch storage of PL/I and then C is allocated when control for a dispatchable unit enters a routine or block and freed when it exits from that routine or block. It cannot, that is, be allocated sooner or freed later. Automatic storage is also LIFO, stack-based storage, allocated from a stack and freed/returned to that stack for reuse. Typically, pools are also stacks, not because FIFO democracy is important for them but because stacks are the easiest constructs to use to manage interchangeable, reusable blocks of storage. Most other storage is non-LIFO, and a block of it is typically called a heap. There are management issues for heaps, but most modern operating systems handle them efficiently. Once allocated from a heap, storage within such a block of can of course be suballocated/managed as a stack or pool. The questions how best to manage heaps and where to put them do not have any generic answers, but the lawyers' de minimis principle is important for them. A system may usefully contain many stacks, but it shouild not usually contain more than a very few heaps. Accesses to heaps must [almost] always be serialized; and adult, asynchronous systems cannot be built without using serialization machinery. Satisfactory systems can be written primarily in some statement-level procedural language (SLPL), but routines written in that SLPL must typically be supplemented by others written in assembly language. The Scots poet Blair described archangelic visits to the earth, necessary to keep things in order here below, as 'short and far between'; and these assembly-language routines can have these two characteristics too. They are, however, necessary 1) to close gaps in the SLPL being used, 2) to avoid really ugly, infelicitous constructs in that SLPL, and to circumvent serious inefficiencies in that SLPL's implementation. For these reasons programmers who do not write assembly language with facility are all but useless. The routines they write always reflect the more or less radical imperfections of the SLPL they use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DELETE VSAM COMPONENTS
Good Day Members, I am trying to delete the VSAM components - data and index - from a disk volume. The problem is that there is a CLUSTER along with the same DATA & INDEX component names which reside on another voume. Is there a way deleting the errant components? Both volumes are SMS managed. Thanks in advance for your help. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On 13 May 2014 12:08, Farley, Peter x23353 wrote: > Perhaps because (at that link which Kirk posted) there is this note: > > "Messages that would normally go to the JESYSMSG data set are captured, but > messages that go to JESMSGLG are not captured." > > Allocation messages go to JESMSGLG, and so it would seem are not captured. > One wonders which bit-bucket they disappear into. I think this is backwards, at least if using the SDSF terminology. What SDSF calls JESYSMSG contains allocation messages (IGD and IEF), while JESMSGLOG is the JESn-captured extract of WTOs written to the system SYSLOG. JESYSMSG also contains *some* application program WTOs, but I haven't put the effort into figuring out which ones. Maybe it's as simple as those with ROUTCDE 11. I've thought about a WTO exit of one sort or another that would capture WTOs from BPXAS processes, and write them to the JES log of their parent process. Of course the parent may have gone away, and there are various other problems, but it should be doable. At least they are already available in the system-wide SYSLOG, but things like allocation messages do indeed seem to go into a bit-bucket. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Loadlib compare utility
Thanks, I'll look into it. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Saturday, May 10, 2014 9:55 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Loadlib compare utility On 5/9/2014 12:47 PM, Lucas Rosalen wrote: > File #182 on CBTTape shows you module sizes, linkage date, etc... then > you can run the "old" loadlib thru the same process and compare > yourself. I'm not aware if it can really compare for you, but you can > get a comparison yourself out of it for sure. I have a copy of something called LOADCOMP in CBT file 860, but haven't used it in ages. It has minor mods, and has comments: AUTHOR: LOU P. RIVAS - UCLA/CCN.JUNE 1977 PROGRAM COMPARE FROM CB&T TAPE FILE 149 That file is in the old MVS tapes section of the CBT. The program loads both modules, reading with BSAM and fudging relocation, so it won't work for PDS/Es? Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN == This email, and any files transmitted with it, is confidential and intended solely for the use of the individual or entity to which it is addressed. If you have received this email in error, please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this e-mail from your system. If you are not the intended recipient, you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Performance for DFDSS with ORACLE Tape Drives VSM5 ( was Change tape block size)
Victor, If I understand problem at the root of your questions, you are trying to speed up DFSMSdss logical dumps, especially for compressed PS-E data sets. >From your questions you are focusing on the tape output rate as the gating >factor for the elapsed time of the dump, but have you looked at the time spent >processing the input files? I may be having a senior moment, but there are two >things that may be affecting the performance of the PS-E data set. (1) I seem >to recall that DFSMSdss will process a compressed PS-E data set at block level >and not attempt to compress it in order to avoid double compression overhead >when COMPRESS is specified, and (2) compressed PS-E data sets do not chain >more than one track of at a time. I'll leave it to you to hit the manuals and >see if I recall correctly. Considered together this means the input file may well be the choke on the backup performance. It may pay to start some RMF monitor II background sessions at 5 second intervals for the input volumes and output tape addresses and have a look at the make-up of response time on both. Omegamon or similar may also provide a delay analysis that shows where the job is spending its time. An extreme consideration would be to ask if you are using FX8S channels and zHPF? Channel microprocessor usage with Extended format IO was one of the many benefits of zHPF and channel throughput from DASD may be part of your problem. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > On Behalf Of Lizette Koehler > Sent: Monday, May 12, 2014 7:11 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: [IBM-MAIN] Performance for DFDSS with ORACLE Tape Drives > VSM5 ( was Change tape block size) > > Victor, > > > The blksize is not the only way to tune a process for efficiency. And in some > cases, there is little you can do to affect some applications like DFDSS. > > If you are using the hardware for tape is virtual tape of oracle, vsm5. Then > there may be nothing more you can do. Sometimes the hardware controls > the process. > > I would open an issue with STK and ask them to assist you with this > configuration. There may be a parm or function unique to STK that may help > you. > > I might also open an SR/ETR with IBM DFDSS to see if they have any > suggestions. > > Lizette > > PS I changed the subject to for more visibility > > > > -Original Message- > > From: IBM Mainframe Discussion List [mailto:IBM- > m...@listserv.ua.edu] > > On Behalf Of Victor Zhang > > Sent: Sunday, May 11, 2014 11:44 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Change tape block size > > > > Hello, > > First I need thank you who replied to my question. > > I should introduce my problem's background and my concern. > > The tape is virutal tape of oralce, vsm5. > > I am backing up extended format PS dataset to VSM5 using ADRDSSU. > > I tested using dss to backup, no matter what block size I specified in > > JCL, ADRDSSU will report same number of blocks in message IEC205I. > > And the backup speed will also be same no matter what block size I > > specified in JCL. > > Here is my testing result: > > st_TIME end_TIMEbackup source data type VOLSER > VTV > > size(mb)VTV size(comp)(mb) tape block size(KB) Total block > count > > reported by DSS backup speed(MB/S) > > 11:31:4111:33:12Extended format compressed AB3968 > > 1854.15 647.77 128 33879 20.38 > > 11:33:1211:34:42Extended format compressed AB3974 > > 1854.15 647.77 64 33879 20.60 > > 11:34:4211:36:17Extended format compressed AB3976 > > 1854.15 647.77 256 33879 19.52 > > > > But this is not true for BASIC PS dataset, for basic PS dataset, I > > did a similar > > testing: > > st_TIME end_TIMEbackup source data type VOLSER > VTV > > size(mb)VTV size(comp)(mb) tape block size(KB) Total block > count > > reported by DSS backup speed(MB/S) > > 13:08:0713:11:37Basic PSAB4075 6273.86 360.15 > > 128 49117 29.88 > > 13:11:3713:16:00Basic PSAB4078 6274.57 367.9 > > 64 98426 23.86 > > 13:16:0013:19:04Basic PSAB4082 6273.51 355.52 > > 256 24528 34.10 > > > > Please note the total block count reported by DSS is different when > > specifying different tape block size. > > > > My goal was: > > To improve backup performance for extended format PS dataset(DB2 > image > > copy on dasd)using ADRDSSU,I am trying to use 256KB to improve > > performace,but I can't. > > Do you have any ideas? > > > > > > Regards > > Victor > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send email to > lists...@listserv.ua.edu with the message: INFO IBM-MAIN -
Re: Where are the allocation messages of a USS process?
Perhaps because (at that link which Kirk posted) there is this note: "Messages that would normally go to the JESYSMSG data set are captured, but messages that go to JESMSGLG are not captured." Allocation messages go to JESMSGLG, and so it would seem are not captured. One wonders which bit-bucket they disappear into. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, May 13, 2014 12:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Where are the allocation messages of a USS process? On Tue, 13 May 2014 10:38:41 -0500, Kirk Wolf wrote: >often the answer is "nowhere". > >See this for a solution: > http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm > Hmmm: o NONE specifies that job log messages are not to be written. This is the default. Ugh! But: user@HOST: export -p | grep BPX export _BPXK_JOBLOG="STDERR" user@HOST: user@HOST: cp "//'sys1.maclib(splevel)'" /dev/null user@HOST: I don't see no allocation messages. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
On Tue, 13 May 2014 10:38:41 -0500, Kirk Wolf wrote: >often the answer is "nowhere". > >See this for a solution: > http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm > Hmmm: o NONE specifies that job log messages are not to be written. This is the default. Ugh! But: user@HOST: export -p | grep BPX export _BPXK_JOBLOG="STDERR" user@HOST: user@HOST: cp "//'sys1.maclib(splevel)'" /dev/null user@HOST: I don't see no allocation messages. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
Having the job step TCB own the storage is the best default for shared storage but it is not always correct. As I said before, shared storage really means when do I free the storage if not specifically freed. Lets use UNIX processes as an example. It is the UNIX equivalent of an MVS job but since there can be thousands, IBM allows multiple processes in a single address space. Terminating a process must free storage that was not specifically freed (e.g. global storage used by threads (TCB) in the process). If all processes use the same job step TCB, then storage for terminated processes would still be allocated. By the way, I suspect (but don't know) that IBM actually has a separate job step TCB for each process. On the ATTACH for a task, you can specify shared user subpools and you can specify SP0 is not shared. SP0 is by default shared. All storage allocated to a shared subpool will assign a storage owner of the first TCB issusing ATTACH with the shared pool (for children/grandchildren TCB's also passing the shared subpool). Using shared subpools is the best method for assigning storage ownership but not always possible. For example an SRB runs without a TCB so it does not have the shared subpools nor a TCB to assign ownership. In this case, you need to specify STORAGE OBTAIN and RELEASE with the TCB you want as owner. I've never allocated / freed storage in an SRB so I can't tell you what if any default TCB is used. Jon Perryman On Tuesday, May 13, 2014 4:33 AM, John McKown wrote: On Mon, May 12, 2014 at 10:11 PM, Jon Perryman wrote: > >> In assembler, we usually do this by allocating the storage to a shared >> subpool or allocating the storage to a TCB that we know is the last TCB to >> terminate. This allows assembler programmers to choose the time that the >> storage will be automatically freed if recovery / termination occurs for >> our task. >> > >Why not just use "Job Step" storage, such as SP=130 or 131? From my >reading, a non-privileged program is allowed to request either of those >subpools, so long as it requests it in a key allowed by the PKM (or just >use key 8). Is this how you are doing it? Or do you use the "input TCB" >parameter of the STORAGE OBTAIN macro? Or do you just have a TCB which does >all the STORAGE OBTAINs. Or, perhaps weirdest, do you schedule an IRB from >the "requesting" TCB to run a subroutine on the "owning" TCB which does the >STORAGE OBTAIN and then returns the address to the original TCB somehow >(such as WAIT / POST)? > >Inquiring minds want to know. I am just curious. > >-- >There is nothing more pleasant than traveling and meeting new people! >Genghis Khan > >Maranatha! <>< >John McKown > > >-- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Where are the allocation messages of a USS process?
often the answer is "nowhere". See this for a solution: http://pic.dhe.ibm.com/infocenter/zos/v1r12/index.jsp?topic=%2Fcom.ibm.zos.r12.bpxb200%2Fjobpro.htm Kirk Wolf Dovetailed Technologies http://dovetail.com On Tue, May 13, 2014 at 6:32 AM, Vernooij, CP (SPLXM) - KLM < kees.verno...@klm.com> wrote: > Hello group, > > We have some dataset problems with USS processes and are looking for the > allocation messages. > I mean the > IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) > DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) > STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () > VOL SER NOS= VIO > and similar that you see in the message file of a job or STC or even in > Syslog for an STC under MSTR. > > Where do these and other messages going for a USS process? > A BPXAS STC is started for the process, but this only contains the > messages for the BPXAS itself. > > Thanks, > Kees. > > > For information, services and offers, please visit our web site: > http://www.klm.com. This e-mail and any attachment may contain > confidential and privileged material intended for the addressee only. If > you are not the addressee, you are notified that no part of the e-mail or > any attachment may be disclosed, copied or distributed, and that any other > action related to this e-mail or attachment is strictly prohibited, and may > be unlawful. If you have received this e-mail by error, please notify the > sender immediately by return e-mail, and delete this message. > > Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its > employees shall not be liable for the incorrect or incomplete transmission > of this e-mail or any attachments, nor responsible for any delay in receipt. > Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch > Airlines) is registered in Amstelveen, The Netherlands, with registered > number 33014286 > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Query for Destination z website -- relocating a data center
My Anaheim SHARE session "15043: zEC12 User Experiences", while ostensibly a hardware discussion, focuses heavily on my first-ever experience of moving production processing to a brand new data center. This project was far more complicated and troublesome than any previous move I'd ever done, which had always entailed moving systems from one data center to another mature one. Some additional observations. -- It makes a big difference if the production move is a one-for-one relocation of discrete components, or a merger into an existing environment. Merger is far more complicated. If there is any choice, move first discretely in a big bang with a minimal outage, then merge later in a gradual process. -- If possible use some kind of DASD mirroring (we have XRC) to populate the new location. Years ago, before mirroring was available, I moved a complex from Phoenix to Seattle using one-off copies of full-volume backup tapes airlifted (!) from city to city. Step up to paying for whatever mirroring will cost. -- For the new data center, other than contractors brought in to perform infrastructure preparation, our own staff did pretty much everything with a lot of advice from vendors, especially IBM. Not every shop is fortunate to have talent with time enough to pull it off, but previous internal relocation projects had honed us for this new task that none of us had ever experienced first hand. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Gabe Goldberg To: IBM-MAIN@LISTSERV.UA.EDU, Date: 05/12/2014 05:25 PM Subject:Query for Destination z website -- relocating a data center Sent by:IBM Mainframe Discussion List Have you moved a data center? What was involved? How much "fun" was it? What was involved, from start to finish? Does the old disruption rule, "two moves equals one fire" apply? Please share lessons learned, gotchas suffered or avoided, "if only" wishes, war stories, etc. Here's some thinking points (not necessarily in project order, listed for completeness)... * Was the move worse than an data center build, initial installation, or upgrade? * Planning * Schedule, timeline, milestones * Logistics * DIY move vs. contractors/subcontractors * Site preparation, e.g., check outlet before plugging in anything too stupid to protect against bad circuit. I saw one vendor's (not IBM) equipment burned out when field manager didn't check power. * Achieving non-stop operation or outage tolerable? * Business continuity during execution * Flexibility during execution * Move equipment vs. install all new? * Incremental move or big-bang cutover? * Parallel operation of old/new data centers? * Back-out plan or point-of-no-return? * Transition period? * Testing * Software licensing * Costs * Results, assessment, postmortem, etc. As usual, please copy reply to me so it's not lost in list digest. Thanks... -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Good News: Introducing Mobile Workload Pricing (MWP) for z/OS
On Tue, 13 May 2014 07:57:04 -0500, Tom Marchant wrote: >On Mon, 12 May 2014 11:32:20 -0500, Paul Gilmartin wrote: > >>o .bin is customarily reserved for DOS executables, which confused me. > >It is? MS-DOS won't run a .bin file, AFAIK. Are you confusing it with .exe? > I stand corrected. If I were a Windows partisan, I'd stand humiliated. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Good News: Introducing Mobile Workload Pricing (MWP) for z/OS
On Mon, 12 May 2014 11:32:20 -0500, Paul Gilmartin wrote: >o .bin is customarily reserved for DOS executables, which confused me. It is? MS-DOS won't run a .bin file, AFAIK. Are you confusing it with .exe? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IBM C and Cobol Threading question
John, Are you speaking of Sub Address Space storage ? Regards, Scott From: john.archie.mck...@gmail.com Sent: Tuesday, May 13, 2014 7:33 AM To: IBM Mainframe Discussion List On Mon, May 12, 2014 at 10:11 PM, Jon Perryman wrote: > In assembler, we usually do this by allocating the storage to a shared > subpool or allocating the storage to a TCB that we know is the last TCB to > terminate. This allows assembler programmers to choose the time that the > storage will be automatically freed if recovery / termination occurs for > our task. > Why not just use "Job Step" storage, such as SP=130 or 131? From my reading, a non-privileged program is allowed to request either of those subpools, so long as it requests it in a key allowed by the PKM (or just use key 8). Is this how you are doing it? Or do you use the "input TCB" parameter of the STORAGE OBTAIN macro? Or do you just have a TCB which does all the STORAGE OBTAINs. Or, perhaps weirdest, do you schedule an IRB from the "requesting" TCB to run a subroutine on the "owning" TCB which does the STORAGE OBTAIN and then returns the address to the original TCB somehow (such as WAIT / POST)? Inquiring minds want to know. I am just curious. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 2014 VM Workshop attendee registration is open for all attendee types: regular, student, sponsor, and spouse!
same-same (== looking for confirmation ) from tuco bonno (aka "sonny") and Tim Connor ; we're both from/with the South Carolina Budget and Control Board in Columba, SC thanks -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Kenneth Barkhau Sent: Tuesday, 13 May, 2014 08:08 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: 2014 VM Workshop attendee registration is open for all attendee types: regular, student, sponsor, and spouse! Hello Mike, I registered several weeks ago. Can you confirm that you have my registration? Ken Barkhau with Hewlett Packard. Thanks much. Ken On Mon, May 12, 2014 at 7:03 PM, Mike Walter wrote: > > > > > The 2014 VM Workshop, June 26-28 2014 will be conducted at North > Carolina A&T State University, Greensboro NC > > > A "Guaranteed Registration" deadline is hard-coded as 11:59 PM Friday > May 30, 2014 due to NC A&T requirements for dorm room setup and, > manufacturer Polo Shirt and T-Shirt production deadlines. All paid > registrations before that deadline are guaranteed to receive: > - one no-charge embroidered 2014 VM Polo Shirt (for regular attendees, > plus any added purchases), > - one no-charge 2014 VM Workshop T-shirt (for students, plus any added > purchases), > - a reserved dorm room (for those who paid for dorm 'nights' - single > rooms are sold out: you'll be paired up with a roommate of the same > gender), > - an "Aggie" debit card pre-loaded with $65 for convenient FOOD > purchases in the campus cafeteria, > - all that above will be available at the VM Workshop registration > table beginning Thursday morning. > Registrations will still be accepted after 11:59 PM Friday May 30, but > after that time no dorm reservations can be accepted, and shirts and > Aggie debit cards will be available on a best-effort basis after > "Guaranteed Registrations" have been processed. > > > > > > WHO: > > z/VM, and Linux on System z Friends > > > > WHAT: > > Location, travel, lodging from dorm rooms ($50/night/bed) up to nearby > hotels, travel hints, sponsor information, and registration details for the > 2013 VM Workshop have all been posted to: http://www.vmworkshop.org/2014 > > Session agenda information will be available on the web site in early > June, following the close of Session Submissions at 11:59 PM on May 30. > > > > WHERE: > > North Carolina A&T State University, Greensboro NC > > > > WHEN: > > SESSION DATES: From Thursday morning JUNE 26 until about 3PM (or so) > Saturday JUNE 28. > > Choose from multiple concurrent presentations packed full of > up-to-the-minute technical sessions for all expertise levels of z/VM, > and Linux on System z, and from Hands-On Labs including: > > - z/VM 6.3.0 Installation or Migration (your choice), > > -'Linux on System z' Installation (SLES or Redhat, your choice), > > - z/VM BFS and SFS Administration (Byte File System and Shared File > System), and > > - more hands-on labs as they are submitted. > > Wednesday June 25 is reserved for VM Workshop Volunteer Committee site > preparation and lab setup, if you are interested in joining just send > me an e-mail asking to join. > > > > WHY: > > Previous VM Workshops have been referred to by the small-minded as: 'a > large number of system programmers with some limited adult > supervision' (do you really want to miss this!??). Expect another > wonderful "up close and personal" workshop with great content and > terrific camaraderie. Come to meet VM old-timers... and *future* z/VM > old-timers while learning the latest technical z/VM and 'Linux on > System z' details. Don't know where to start with Linux on System z? This > is a great place to start! > > > > PRICE: > > STILL UNCHANGED from the previous three years, ** ONLY $100 per > attendee**, optional dorm rooms with full linens are available for > $50/night/bed. This is the best bargain out there for z/VM and 'Linux > on System z' education, and is quite reasonable for anyone paying > their own way. Parking is available on-site for $6 per day. > > > > Regular attendees and sponsor attendees: The $100 registration fee for > regular attendees includes: access to all sessions and hands-on labs, > a snazzy 2014 VM Workshop polo shirt (not just a cheap T-shirt like > those high-priced conferences), a Gala Dinner Reception on Thursday > evening, and... attendees will be provided with an NC A&T "Aggie" > debit card loaded with $65 to purchase other meals and snacks on campus. > > > > Full-time Students: A $10 registration fee includes: access to all > sessions and hands-on labs, a 2014 VM Workshop T-shirt (sure to become > a campus "must have"), and optional ($15) attendance at the Gala > Dinner Reception on Thursday evening. > > > > Spouse attendees: A $0 registration fee provides: an optional means of > purchasing a dorm room bed ($50/night/bed), and/or attendance at the > Gala Dinner Reception on Thursday evening ($20). > > > > H
Re: 2014 VM Workshop attendee registration is open for all attendee types: regular, student, sponsor, and spouse!
Hello Mike, I registered several weeks ago. Can you confirm that you have my registration? Ken Barkhau with Hewlett Packard. Thanks much. Ken On Mon, May 12, 2014 at 7:03 PM, Mike Walter wrote: > > > > > The 2014 VM Workshop, June 26-28 2014 will be conducted at North Carolina > A&T State University, Greensboro NC > > > A "Guaranteed Registration" deadline is hard-coded as 11:59 PM Friday May > 30, 2014 due to NC A&T requirements for dorm room setup and, manufacturer > Polo Shirt and T-Shirt production deadlines. All paid registrations before > that deadline are guaranteed to receive: > - one no-charge embroidered 2014 VM Polo Shirt (for regular attendees, > plus any added purchases), > - one no-charge 2014 VM Workshop T-shirt (for students, plus any added > purchases), > - a reserved dorm room (for those who paid for dorm 'nights' - single > rooms are sold out: you'll be paired up with a roommate of the same gender), > - an "Aggie" debit card pre-loaded with $65 for convenient FOOD purchases > in the campus cafeteria, > - all that above will be available at the VM Workshop registration table > beginning Thursday morning. > Registrations will still be accepted after 11:59 PM Friday May 30, but > after that time no dorm reservations can be accepted, and shirts and Aggie > debit cards will be available on a best-effort basis after "Guaranteed > Registrations" have been processed. > > > > > > WHO: > > z/VM, and Linux on System z Friends > > > > WHAT: > > Location, travel, lodging from dorm rooms ($50/night/bed) up to nearby > hotels, travel hints, sponsor information, and registration details for the > 2013 VM Workshop have all been posted to: http://www.vmworkshop.org/2014 > > Session agenda information will be available on the web site in early > June, following the close of Session Submissions at 11:59 PM on May 30. > > > > WHERE: > > North Carolina A&T State University, Greensboro NC > > > > WHEN: > > SESSION DATES: From Thursday morning JUNE 26 until about 3PM (or so) > Saturday JUNE 28. > > Choose from multiple concurrent presentations packed full of > up-to-the-minute technical sessions for all expertise levels of z/VM, and > Linux on System z, and from Hands-On Labs including: > > - z/VM 6.3.0 Installation or Migration (your choice), > > -'Linux on System z' Installation (SLES or Redhat, your choice), > > - z/VM BFS and SFS Administration (Byte File System and Shared File > System), and > > - more hands-on labs as they are submitted. > > Wednesday June 25 is reserved for VM Workshop Volunteer Committee site > preparation and lab setup, if you are interested in joining just send me an > e-mail asking to join. > > > > WHY: > > Previous VM Workshops have been referred to by the small-minded as: 'a > large number of system programmers with some limited adult supervision' (do > you really want to miss this!??). Expect another wonderful "up close and > personal" workshop with great content and terrific camaraderie. Come to > meet VM old-timers... and *future* z/VM old-timers while learning the > latest technical z/VM and 'Linux on System z' details. Don't know where to > start with Linux on System z? This is a great place to start! > > > > PRICE: > > STILL UNCHANGED from the previous three years, ** ONLY $100 per > attendee**, optional dorm rooms with full linens are available for > $50/night/bed. This is the best bargain out there for z/VM and 'Linux on > System z' education, and is quite reasonable for anyone paying their own > way. Parking is available on-site for $6 per day. > > > > Regular attendees and sponsor attendees: The $100 registration fee for > regular attendees includes: access to all sessions and hands-on labs, a > snazzy 2014 VM Workshop polo shirt (not just a cheap T-shirt like those > high-priced conferences), a Gala Dinner Reception on Thursday evening, > and... attendees will be provided with an NC A&T "Aggie" debit card loaded > with $65 to purchase other meals and snacks on campus. > > > > Full-time Students: A $10 registration fee includes: access to all > sessions and hands-on labs, a 2014 VM Workshop T-shirt (sure to become a > campus "must have"), and optional ($15) attendance at the Gala Dinner > Reception on Thursday evening. > > > > Spouse attendees: A $0 registration fee provides: an optional means of > purchasing a dorm room bed ($50/night/bed), and/or attendance at the Gala > Dinner Reception on Thursday evening ($20). > > > > HOW: > > Registration is now LIVE, please check it out soon! (Live servers are > standing by to take your registration!) > > Advice: onsite registration is not likely, and will involve additional > fees to the university and thus... to you, so register now! > > > > PARTICIPATE: > > Compete in the historical (occasionally hysterical) VM Workshop "Ugly > Hawaiian Shirt" contest for a chance to win a treasured, but ugly prize! > (B.Y.O.U.H.S.) > > > > The VM Workshop began as a way for VM systems programmers to share what > they do at t
Re: IBM C and Cobol Threading question
On Mon, May 12, 2014 at 10:11 PM, Jon Perryman wrote: > In assembler, we usually do this by allocating the storage to a shared > subpool or allocating the storage to a TCB that we know is the last TCB to > terminate. This allows assembler programmers to choose the time that the > storage will be automatically freed if recovery / termination occurs for > our task. > Why not just use "Job Step" storage, such as SP=130 or 131? From my reading, a non-privileged program is allowed to request either of those subpools, so long as it requests it in a key allowed by the PKM (or just use key 8). Is this how you are doing it? Or do you use the "input TCB" parameter of the STORAGE OBTAIN macro? Or do you just have a TCB which does all the STORAGE OBTAINs. Or, perhaps weirdest, do you schedule an IRB from the "requesting" TCB to run a subroutine on the "owning" TCB which does the STORAGE OBTAIN and then returns the address to the original TCB somehow (such as WAIT / POST)? Inquiring minds want to know. I am just curious. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Where are the allocation messages of a USS process?
Hello group, We have some dataset problems with USS processes and are looking for the allocation messages. I mean the IGD101I SMS ALLOCATED TO DDNAME (DSNIWK02) DSN (SYS14131.T210019.RA000.XI1DMS1A.R0141149) STORCLAS (SCBATCH) MGMTCLAS () DATACLAS () VOL SER NOS= VIO and similar that you see in the message file of a job or STC or even in Syslog for an STC under MSTR. Where do these and other messages going for a USS process? A BPXAS STC is started for the process, but this only contains the messages for the BPXAS itself. Thanks, Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
