Re: Mainframe hacking
On Sun, Jul 19, 2009 at 10:51 PM, Gainsford, Allen wrote: > Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know > exactly how to do it. :) Ouch. Besides the technical inaccuracies, that book was irritating because for no apparent reason it misplaced University of Waterloo, putting it near the wrong highway. "When Harlie Was One" is a better example of the sub-genre, along with "The Moon Is A Harsh Mistress", of course. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
> Does anyone here recall any published news articles or incidents > involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you > personally know of any incidents? > > Or have any such been kept on the QT? Anyone who's read "The Adolescence of P-1" by Thomas Ryan will know exactly how to do it. :) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: INFOZIP >2Gb
On Friday 17 July 2009, Chase, John wrote: > > -Original Message- > > From: IBM Mainframe Discussion List On Behalf Of Bob Woodside > > > > [ snip ] > > > > The old version of bzip2 that used to be available from IBM has > > been withdrawn; I don't know what version it was or whether it > > supported large files. There is now a "supported" version which you > > have to pay for, and looks to be heavily modified by IBM - mainly to > > provide IBM-style messages, as far as I can tell. I can't imaginw > > wanting such a beast, but that's the subject of a different thread! > > Well, bzip2 from IBM is now a part of the "Licensed Program Product" > called "IBM Ported Tools" or similar, but it's a "no-charge" product; > i.e., you do have to "license" it now, but it still doesn't cost any > money. Oops - I didn't read the IBM Ported Tools description closely enough, and missed the words "a non-priced program product". My apologies. I still think I'd rather have a straight build of the latest version (hmm, come to think of it, I guess I do now!), because: 1) I see small value in having a lot of IBM mods just to fit the messages into an IBM-style scheme. As always,YMMV. (I wouldn't have a problem with this if the mods were fed back to the bzip2 developers and became a part of the regular code base rather than being a separately maintained IBM fork. I like standardized message prefixes and good documentation as well as the next person. No, really.) 2) The Supplementary Toolkit version appears to be 1.0.4, which is documented to have a potential security vulnerability (CERT-FI 20469, corrected in 1.0.5). Cheers, Bob -- Bob Woodside Woodsway Consulting, Inc. http://www.woodsway.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
I had one once, circa 1992-1993. It was at a university, which at the time were notoriously open, at least as far as TCPIP and a firewall. Someone got the uss screen, was able to get into the production CICS, and the CECI command was not protected, so they were able to shut the CICS down. The hack came from Brazil somewhere. Bank of Brazil maybe? Mary Anne On Sun, Jul 19, 2009 at 5:47 PM, P S wrote: > Does anyone here recall any published news articles or incidents > involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you > personally know of any incidents? > > Or have any such been kept on the QT? > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: IBM error messages getting worse?
On Fri, 17 Jul 2009 18:32:29 -0600, Frank Swarbrick wrote: >I have a very basic one to complain about: > >DFS0929I BLDL FAILED FOR MEMBER --DDMPPSZ > >This really means that the specified PSB DDMPPSZ is not in the >specified IMS library. Why can't it just say that? As an application > programmer do I really need to know that BLDL means, well, >whatever it means? >... I think this is a pretty common example of an error message saying "what" rather than "why". Maybe it was written by a coder that had no idea why the BLDL was issued or a developer who was just too close too close to the code. It's accurate but not helpful. But I doubt this is much more common now than in the past. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
Key bounce... Must have been a gremlin... John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Sunday, July 19, 2009 5:53 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Mainframe hacking You don't say? :-) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
To my knowledge, there has never been a documented case of an external user compromising a mainframe system "without inside assistance". John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Sunday, July 19, 2009 5:47 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe hacking Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
You don't say? :-) On Sun, Jul 19, 2009 at 5:51 PM, John P. Baker wrote: > John P. Baker > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf > Of P S > Sent: Sunday, July 19, 2009 5:47 PM > To: IBM-MAIN@bama.ua.edu > Subject: Mainframe hacking > > Does anyone here recall any published news articles or incidents > involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you > personally know of any incidents? > > Or have any such been kept on the QT? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Mainframe hacking
John P. Baker -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of P S Sent: Sunday, July 19, 2009 5:47 PM To: IBM-MAIN@bama.ua.edu Subject: Mainframe hacking Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Mainframe hacking
Does anyone here recall any published news articles or incidents involving mainframe hacking (any flavor of VM, VSE or MVS)? Do you personally know of any incidents? Or have any such been kept on the QT? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Messages as Programming Interfaces
Our automation system relies heavily on the content of messages and has not failed us in 10 versions of z/OS. We have an automation product that reads the text of messages and enables the execution of tasks, depending on the text and passing extract of text to subroutines. I have never seen a directive against this practice. On Mon, Jul 6, 2009 at 9:07 PM, Paul Gilmartin wrote: > It is my understanding that IBM discourages the use of > message texts as programming interfaces. Can anyone > point me to a clear statement of this in IBM documentation? > > (Notwithstanding that IBM is very reluctant to change > messages lest that disrupt automated operations.) > > Thanks, > gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: job started with SUB=MSTR without the owner information
There is no jobid unless the task attaches to JES and requests one. The task itself must request the connection and cannot be assigned from the outside. On Fri, Jun 5, 2009 at 1:43 AM, Tommy Tsui wrote: > Hi all, > > I try to started a system task APPC with SUB=MSTR but can't find the > owner/user or jobid information even we defined a started task to > APPC.* . How can we assign a owner to this system task? > > > Any help will be appreciated > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Message Flood Automation in z/os 1.9
Is it easier to implement message flood the way IBM have implemented it or to use one of the message automation products that offer the MPF exit as one of its options? On Wed, Jul 1, 2009 at 4:07 PM, Klein, Kenneth wrote: > > > Actions for OA25602: > > Before the installation of this APAR, if you implemented > exit specified in parmlib member MPFLSTxx and with message > processing installation exit IEAVMXIT. With this APAR, > Message Flood Automation is integrated in z/OS, eliminating > the use for the exit routines. Message Flood Automation must > be removed from these exit routines: > > Steps to take: > > - Update your MPFLSTxx parmlib member to remove all > .CMD USEREXIT(CNZZCMXT) statements. > > - If you have a CONTROL M (K M) command in your CONSOLxx > or yout COMMNDxx, you must remove it. > > - If you use exit IEAVMXIT only for Message Flood > Automation, update your CONSOLxx parmlib member to > change the INIT statement option of UEXIT(Y) to > UEXIT(N). Note: Do not do this if you want to > continue to use IEAVMXIT for other > purposes. > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville > kenneth.kl...@kyfb.com > 502-495-5000 x7011 > > -Original Message- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Skip Robinson > Sent: Wednesday, July 01, 2009 1:28 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: Message Flood Automation in z/os 1.9 > > I don't have the HOLD data in front of me, but as I recall 'exit > removal' > referred only to message suppression logic, not to the exit per se. For > example, we use the exit to set message color by system, not for > suppression. The exit is still in place and working fine. I think the > HOLD record is poorly worded and misleading, but the gist is there if > you ponder it long enough. > > . > . > JO.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 > > > > > "Klein, Kenneth" > > > FB.COM> > To > Sent by: IBM IBM-MAIN@bama.ua.edu > > Mainframe > cc > Discussion List > > Subject > .edu> Message Flood Automation in z/os > > 1.9 > > > > 07/01/2009 09:44 > > AM > > > > > > Please respond to > > IBM Mainframe > > Discussion List > > > .edu> > > > > > > > > > > The hold(action) states the userexit is to be removed from the mpflst, > and in consolxx the uexit be set to (N). > So how does the integrated mfa know which messages to suppress? > Any other actions required beyond whats in the hold data? > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search > the archives at http://bama.ua.edu/archives/ibm-main.html > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Post not in Archive but in Google Groups
In article you write: >I follow the list using Google Groups digest in order to be prompted to check >topics and the archives for when I want to contribute. > >From time to time with a topic which appears in the Google Groups digest in >which I may be interested I discover that a post has not managed to get into >the archives while it is found - bright-eyed and bushy-tailed - in Goggle >Groups. > >Has anyone an explanation for that and, if so, have they any standard advice >I can pass on to the contributor who very possibly is not getting to the >audience he or she thinks he or she should be reaching and possibly whose >erudite contributions will not be getting into the archive that matters to say >nothing of the contributor waiting for the gem that is going to solve >his or her >problem - possibly disguised as an "issue"? No, its not an issue, its just an artifact of how this list works. You may not realize it but there are TWO entities called IBM-MAIN. One is a mailing list hosted at the listserver at bama.ua.edu. The second is the usenet group named "bit.listserv.ibm-main". The mailing list has a gateway to the usenet group but there is no reverse gateway. There used to be but it was taken down due to abuse. So if someone originates a post by sending it to the mailing list, it will appear there and ALSO on the usenet group. But if someone originates a post on usenet, it will not be sent to the mailing list. Google Groups is fed from usenet so it is complete. The mailing list archives are ONLY fed by the listserv so they will miss anything that was only posted on usenet. For folks who normally read usenet or Google Groups (which IS usenet although Goggle would like you to believe otherwise) here is what I do and what I suggest all usenet readers do also: 1) Subscribe to the mailing list. 2) Set yourself to NOMAIL on the listserv. 3) When responding to a usenet post, DON'T use Followup. Instead use Reply and make sure that the email address gets set to: "To: IBM-MAIN@bama.ua.edu". That way your response will be seen on both the mailing list and on usenet, and will be in the IBM-MAIN archives at bama. -- Rich Greenberg N Ft Myers, FL, USA richgr atsign panix.com + 1 239 543 1353 Eastern time. N6LRT I speak for myself & my dogs only.VM'er since CP-67 Canines:Val, Red, Shasta & Casey (RIP), Red & Zero, Siberians Owner:Chinook-L Retired at the beach Asst Owner:Sibernet-L -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Post not in Archive but in Google Groups
I follow the list using Google Groups digest in order to be prompted to check topics and the archives for when I want to contribute. >From time to time with a topic which appears in the Google Groups digest in which I may be interested I discover that a post has not managed to get into the archives while it is found - bright-eyed and bushy-tailed - in Goggle Groups. Has anyone an explanation for that and, if so, have they any standard advice I can pass on to the contributor who very possibly is not getting to the audience he or she thinks he or she should be reaching and possibly whose erudite contributions will not be getting into the archive that matters to say nothing of the contributor waiting for the gem that is going to solve his or her problem - possibly disguised as an "issue"? If you want an example - the straw that broke the camel's back which prompted this request - the last contribution in the tortured thread "3174-1 pack system" from Bruce McKnight appears in Google Groups but does not appear in the IBM-MAIN archicves. Chris Mason -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: 3174-1 pack system
Ron Let's try a diagram: PC with TN3270 client <-IP network-> TN3270 server/pre-SNA 3270 controller device <-channel-> z/OS LPAR You will see that the "TN3270 server" is separated from the z/OS LPAR with a channel of some sort. Over this "channel" the TN3270 server and z/OS operate channel programs which function just like those used by pre-SNA (non-SNA) 3270 local controllers, most recently the 3174-L models and originally, in the early '70s, the 3272. Thus the console function of z/OS imagines it is dealing with one of those pre- SNA 3270 controllers. The fact that the device attached at the other end of the channel connection happens to operate a TN3270 server function is of no interest whatsoever to z/OS and makes no demands upon it other than the ability to run channel programs. How loudly can I say this? There is no need for any vestige of the Communications Server IP component - or any UNIX System Services files that the Communications Server IP component may need - in the z/OS system using one of these "TN3270 server/pre-SNA 3270 controller devices" as a console. I hope that is abundantly clear! One of the implementations of the "TN3270 server/pre-SNA 3270 controller device" is the OSA in ICC mode. You can read about this device in the regular manual http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IOA2M110/ or the redbook http://www.redbooks.ibm.com/abstracts/sg246364.html John McKown and Mark Zelden - he of infinite patience - mentioned some alternatives to the ISA in ICC mode. - Although you didn't mention the need, others have mentioned that, just as it is possible to use a 3270 display device connected with a pre-SNA 3270 controller either as a console or, apparently, in an SNA session, you can use the PC in the diagram above in the same way. The way it works as a device apparently supported by SNA is that VTAM supplies a protocol conversion from pre-SNA channel programs supporting individual devices, displays or printers, logically connected through a pre-SNA controller to a specific 3270 data stream implementation of LU type 0. This protocol conversion is described in Chapter 11. "Programming for the IBM 3270 Information Display System" of the Communications Server SNA Programming manual. - Finally you should be aware that the use of the abbreviation "USS" in the context of TN3270 is ambiguous. At the risk of confusing you, I can mention that, if this query involved the Communications Server IP TN3270 component - which it emphatically does not!, USS would correctly refer to VTAM's Unformatted System Services function as highjacked by the IP component of Communications Server for support of the clients using the Communications Server IP TN3270 server. However, since, as I have said now many times, we are *not* talking about the Communications Server IP TN3270 server, even those "USS files" are not relevant and are not required. Chris Mason On Fri, 17 Jul 2009 15:02:34 -0500, Ron Wells wrote: >Ah remember (1) pack recovery system... >Looking at an alternative to needing (2) packs-with TCPIP/OMVS I need >another volume.. >Looking for an alternative to get my 3270-console without the need of >tcpip amd all the uss files needed.. > >any one out there have any ideas... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: NVAS error "explanation" RESOLVED
John Glad to have been of assistance. > So, it looks like we forgot to configure NVAS to support "modern" emulators (my default MODEENT is D4C32XX3, which NVAS apparently presents to VTAM as DYNAMIC). When I override the MODEENT at CINIT time with EXT32782 (locally-defined clone of SNX32702 but with smaller RUSIZEs), the "relay mode" logons within NVAS work but I'm "stuck with" a 24x80 screen size. I think I finally worked out what you are saying here. You first post was about a message which indicated total failure to start the relay session. Now you are adding that you succeed in getting a relay session but only when you override the LOGMODE parameter (the name of the MODEENT macro in the mode table) with EXT32782 - rather than D4C32XX3, when you enter the equivalent of the LOGON command (which goes on to create a request which eventually enters NVAS as the SNA CINIT request). However your relay session does not have the presentation space dimensions you want. In other words I would have preferred it if you had said "When, in my USS (Unformatted System Services) LOGON command, I specify EXT32782 in order to override the default LOGMODE parameter ..." in place of "When I override the MODEENT at CINIT time with EXT32782 ..." That way people reading the archives for elucidation stand a chance of following what is going on without having to puzzle themselves too much! Anyhow, looking at the codes you mentioned from the message in the NVAS log, we can determine the following: RPLREQ = X29 means that the VTAM request was a REQSESS, the call used to request that the local SSCP, VTAM, initiates a session where the current program will be the *secondary* LU in the session. Incidentally, you have to know to go to an Appendix of the Communications Server SNA Programming manual and then look up a control block code in order to be able to translate this code to something that might start to mean anything to you! RTNCD = X14 translates to decimal 20 and, in the panoply of VTAM error conditions, one which is assigned the generic code 20 officially means that the program is still in development and that the programmer needs to go and sort out a logic error! FDBK2 = X4B is the more specific code within the generic return code. This is described as the following: INTRPRET sequence or LOGMODE not valid, or cryptographic incompatibility which is still pretty general but at least mentions LOGMODE so, if you know you are not using an INTRPRET sequence or cryptography, you may now be focused on something to do with mode table entries. The further explanation, stripped down to the LOGMODE angle, says the following: You issued an INQUIRE, OPNDST, SIMLOGON, REQSESS, or CLSDST OPTCD=PASS macroinstruction. Either the NIB for this request specified a logon mode name that could not be found in the logon mode table for the logical unit named in that NIB or . SENSE = X08210002 means the following: Sense code 0821 Session parameters not valid: Session parameters included on a BIND were not valid or not supported by the half-session whose activation was requested. The session parameters are usually obtained from the logmode table entry. Bytes 2 and 3 following the sense code contain sense-code-specific information. 0002 Mode name at CP not valid: The specified mode name was not recognized by the CP. which actually tells us no more that the RTNCD=X14/FDBK2=X4B did. There are a number of those usually very helpful "VTAM hints" in the Communications Server IP and SNA Codes manual. However, they do not address what I guess NVAS has done which is to try to specify a particular mode name for the session for whatever reason. It seems you are aware of whatever these internal machinations on the part of NVAS are and know what needed fixing - once you had appreciated that NVAS was feeding VTAM an invalid mode table entry name for the ongoing relay session to CICSTECH. > (my default MODEENT is D4C32XX3, which NVAS apparently presents to VTAM as DYNAMIC). Presumably the explanation is somewhere in there. I don't know where DYNAMIC comes from here. It is not a mode table entry name in ISTINCLM although there could be such an entry in a private mode table which would need to be available to the NVAS APPL statement used for the relay session to CICSTECH. The name DYNAMIC may be related somehow to the TN3270 "device code" DYNAMIC or IBM-DYNAMIC which maps to mode table entry name D4C32XX3 by default. Chris Mason On Fri, 17 Jul 2009 09:08:50 -0500, Chase, John wrote: >> -Original Message- >> From: IBM Mainframe Discussion List On Behalf Of Chris Mason >> >> John >> >> I'm not familiar with NVAS but this messages looks like the sort that >is >> presented to a feeble end user who could not cope with complicated >technical >> explanations and so the ridiculous words "network constraints" are >used which >> could means anything. >> >> Looking at the NVAS Messa
