Re: Is there currently a way to access MongoDB from z/OS LE languages?
On 25/10/2013 1:51 PM, Rob Schramm wrote: With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA procedure BCDBATCH to help tie the two together. Did a quick scan and there appear to be at least few JDBC drivers. I'm scratching my head as to why a JDBC driver is useful with a NoSQL data base which has a very specific API. Why not just use the MongoDB Java API? Does JDBC provide some kind of value add? Rob Rob Schramm Senior Systems Consultant Imperium Group On Fri, Oct 25, 2013 at 1:18 AM, David Crayford dcrayf...@gmail.com wrote: On 25/10/2013 12:28 PM, Tony Harminc wrote: On 24 October 2013 23:49, Ze'ev Atlas zatl...@yahoo.com wrote: About a previous post, the endianess should not be a big issue to deal with once the two sides of the protocol are well defined. The EBCDIC issue is a make or break issue. MongoDB works decidedly with UTDF-8 and I need COBOL to natively view a string as UTF-8. Does the current incarnation of COBOL (and perhaps PL/I) have a native UTF-8 string type. If not, then I will abandon the whole project. I'm doubtless blowing (or something) into the wind again, but this sounds like a place for UTF-EBCDIC. Which is easily translated to and from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8 was just a typo.) Presumably it would be a good start if COBOL could see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings that would live as UTF-8 in the database. Then when COBOL learns to handle UTF-EBCDIC, it could handle the complete UNICODE set. The wire protocol is binary. The UTF-8 requirement for strings in the BSON spec http://bsonspec.org/#/**specificationhttp://bsonspec.org/#/specification . I really like the look of BSON. It's like google protocol buffers but more flexible. XML is the pleated khakis of the document markup world. http://www.unicode.org/**reports/tr16/http://www.unicode.org/reports/tr16/ Tony H. --**--** -- 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 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: GDG question
This Friday post of an old MXG change documents a unique problem with GDG wrapping, and the unwillingness of the IBM catalog technician (a/k/a trench holder) to provide the documentation of their catalog records back in 2005. Maybe he was afraid that MicroSoft would offer a competing catalog product??? Barry Change 23.219 The ICF Catalog 05 record variable GATGEN should have VMAC6156 been input as PIB.2., instead of one byte, and variable VMACCTLG GATWRAP='Y' is now set if the first bit of GATGEN is on, Aug 29, 2005 to mark that this GDG member has wrapped; i.e., its generation number has exceeded . If GATWRAP is on, GATGEN=GATGEN-32768 to contain the correct Gen number. This discovery was precipitated by IGD07001I ABENDs in production, which occurred when a GDG that had GATWRAP on for some members, and GATWRAP off for others, when that GDG generation number goes from 999 to 1000. Normally, when all members of a GDG have wrapped, the next catalog action turns off the wrap bit in all of the catalog records. For a normal GDG, that should happen when the +256th gen is created after wrap, as only 255 members can exist in the catalog. But this site had had a very old application that originally created +1 thru +5 each day, and then deleted +1 thru +4, leaving only +5 in the catalog. However, back when Clinton was President, an application change was made that created only +1 thru +3 and deleted only +1 and +2, so there were 2 old GVoo's left in the catalog. When the GDG wrapped, and when the create of +1 would have created G1000V00, those old GVoo's still had their wrap bit off, and the production job failed: IGD07001I; GDG ROLL IN ERROR - RETURN CODE 140 REASON 122 Return Code 140: Inconsistent or conflicting arguments were provided. Reason Code 122: Catalog G1000Vxx will cause the GDG to exceed the limit of 10,999. Programmer Response: Clean up the GDG in error then catalog G1000Vxx. The site found Information APAR II07276, which explained how wrap works, but it says to 'see the Z page for internal details of the wrap bit interface'. So the site asked IBM Support: We need to identify other GDGs that have the same exposure to causing ABENDs. Can I look at the 'Z' page? Does the 'wrap bit' appear in SMF 61, 65, 66 ICF Catalog records? IBM Level 2 Catalog Support refused to answer the quite valid question, with this answer: Unfortunately, the 'Z' page in our info APARs refer to information meant for IBM eyes only, for helping us get to problem determination quicker. We are not at liberty to discuss any control block internals that are not provided in our published manuals. As for information in SMF records relating to this, this info would be included in the updated record portion of the SMF record, however we cannot discuss offsets for those either. I am sorry I cannot be more helpful. Please let me know if there are any other questions that I can answer for you. Even escalation to my IBM Poughkeepsie z/OS support did not convince IBM Level 2 Catalog Support to identify which bit is the GATWRAP bit. The ICF Support and Developers hid behind OCO, Object Code Only, as the reason they could not provide catalog record documentation (but DSECTS are NOT CODE!). So I suggested the site could create a GDG and force it to wrap, and by examining SMF records, we concluded that first bit of GATGEN was the GATWRAP bit. Then, I remembered I still had lots of archaic printed manuals, and located the very old MVS/XA Catalog Diagnosis Reference for DFP Release 1.2, which confirmed that the GATWRAP bit was indeed the first bit of the GATGEN field in the 05 Catalog Record! -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Rob Schramm Sent: Friday, October 25, 2013 12:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: GDG question Phil, AFAIK, the whole GDG assignment only happens once.. during initial creation. MODing will change the
Re: z/OS IPL Issue
Mike, The use of the Integrated 3270 is not limited to the model of use embodied by z/OS MCS console interaction (e.g. a single line of input) but rather supports a broader range of the 3270 data stream. In z/OS terms think about the possibility (not currently available) of having a TSO session running ISPF available. With this use in mind I think you can see fighting about keyboard inputs would be very difficult. (Note: VM does support the use of the Integrated 3270 for a virtual machine console which could result in an ISPF presentation.) I think the current limitation of not allowing multiple concurrent accessors represents a typical first implementation (i.e. very conservative) that the designers of z are wont to do. My suggestion would be that anyone who is interested in seeing this change find Ed Jaffe's requirement and concur with it or alternatively open a similar requirement of their own. Like many other features/functions of the z platform the Integrated 3270 does not behave exactly was one might like but none the less even with it's current limitations it is useful. John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Getting the SMF time
I already convert the SMF time into human time by using arithmetic but I am having a problem with the calculation and I am attempting to use the ASM macros to convert the time. Here is what I am doing: * CREATE TODDATE MVC SMFDATE,SMF2DTE MVI SMFDATE,X'20' L R2,SMFDATE R2 X'20YYDDDS' SRL R2,4R2 X'020YYDDD' STR2,CVDATE CVDATE XL4 X'020YYDDD' MVC CVZERO,ZERO CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD * SET TIME L R2,TODTIME A R2,SMF2TME STR2,TODTIME This returns what looks to me to be a good TODCLOCK TODCLOCK +0 CC208E64 F236F8F4 Now I do a STCKCONV STCKVAL=TODCLOCK,CONVVAL=TMECVTD,DATETYPE=MMDD, + TIMETYPE=DEC It returns: TMECVTD +0 0867 10182013 The time is not correct (the date is). Any ideas on what I am doing wrong? By my calculations the time should be 14:52:00.16. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG question
On Thu, 24 Oct 2013 21:25:50 -0700, Phil Smith wrote: But the data is also shared across tasks, so we don't want a window where it's half-written and some task tries to read it. UNIX files provide the natural solution to such a requirement in that the UNIX rename() is preemptive and atomic: o Preemptive in that rename() replaces any previously existing file (directory entry, actually) having the new name. o Atomic in that the operation is serialized by the kernel so that no other process doing a search for the file can encounter a window during which the file is not found. There ought to be a Requirement to provide a similar facility in IDCAMS. PDSE does very similarly for PDSE members. Can you use PDSE members? I regularly make use of this using FTP, actually, to install updated versions of certain files: PUT updated-file tempname RENAME tempname static-name A couple times an observant user has spotted the tempname file while the operation was progress and asked me to explain its existence. But he never had to deal with an incomplete file. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting the SMF time
On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote: TMECVTD +0 0867 10182013 The time is not correct (the date is). Any ideas on what I am doing wrong? By my calculations the time should be 14:52:00.16. Since IBM refuses to document the behavior of STCKCONV (they say it should be common knowledge in response to my RCF), it's pretty hard to say any result is right or wrong. And it has been discussed here that among various SMF record types there are radically different conventions for representation of the timestamp. Some argue that this is proper given radically different requirements for range, precision, and API among those various various record types. I'm unmoved by the argument. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG question
Gil, I wonder if said observant user would notice a file name which started with a period, followed by the characters newversion-of', another period, then the original file name? E.g. PUT updated-file .newversion-of.static-name RENAME .newversion-of.static-name static-name On Fri, Oct 25, 2013 at 9:05 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Thu, 24 Oct 2013 21:25:50 -0700, Phil Smith wrote: But the data is also shared across tasks, so we don't want a window where it's half-written and some task tries to read it. UNIX files provide the natural solution to such a requirement in that the UNIX rename() is preemptive and atomic: o Preemptive in that rename() replaces any previously existing file (directory entry, actually) having the new name. o Atomic in that the operation is serialized by the kernel so that no other process doing a search for the file can encounter a window during which the file is not found. There ought to be a Requirement to provide a similar facility in IDCAMS. PDSE does very similarly for PDSE members. Can you use PDSE members? I regularly make use of this using FTP, actually, to install updated versions of certain files: PUT updated-file tempname RENAME tempname static-name A couple times an observant user has spotted the tempname file while the operation was progress and asked me to explain its existence. But he never had to deal with an incomplete file. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting the SMF time
If I were in charge (no chance), I would go with exactly TWO different versions of a time stamp on z/OS. A binary one, which just happens to be identical to the output of the STCKE instruction (16 bytes, 128 bits). And a character one which is the full ISO8601 format ( mmddThhmmss.s+hh:mm ). And some system function which translates between the two. I don't really know if 5 digits after the decimal point is the best precision. And the + is a + or - and is based on the offset kept in the CVT. While I'm at it, the default TZ in LE and UNIX, if not specifically set, should also be assumed to be the equivalent of what the offset is in the CVT. On Fri, Oct 25, 2013 at 9:16 AM, Paul Gilmartin paulgboul...@aim.comwrote: On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote: TMECVTD +0 0867 10182013 The time is not correct (the date is). Any ideas on what I am doing wrong? By my calculations the time should be 14:52:00.16. Since IBM refuses to document the behavior of STCKCONV (they say it should be common knowledge in response to my RCF), it's pretty hard to say any result is right or wrong. And it has been discussed here that among various SMF record types there are radically different conventions for representation of the timestamp. Some argue that this is proper given radically different requirements for range, precision, and API among those various various record types. I'm unmoved by the argument. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Not sure how to respond.. on the one hand you have an excellent point. One the other hand.. Google jdbc and mongodb.. as well as there being a jdbc link on the mongodb page in addition to the mongodb java connectors. Doesn't really change my intent ... Grab the mongodb java database driver.. (how does jmdbc driver sound???) and couple it with the cobol application code. Rob On Oct 25, 2013 3:03 AM, David Crayford dcrayf...@gmail.com wrote: On 25/10/2013 1:51 PM, Rob Schramm wrote: With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA procedure BCDBATCH to help tie the two together. Did a quick scan and there appear to be at least few JDBC drivers. I'm scratching my head as to why a JDBC driver is useful with a NoSQL data base which has a very specific API. Why not just use the MongoDB Java API? Does JDBC provide some kind of value add? Rob Rob Schramm Senior Systems Consultant Imperium Group On Fri, Oct 25, 2013 at 1:18 AM, David Crayford dcrayf...@gmail.com wrote: On 25/10/2013 12:28 PM, Tony Harminc wrote: On 24 October 2013 23:49, Ze'ev Atlas zatl...@yahoo.com wrote: About a previous post, the endianess should not be a big issue to deal with once the two sides of the protocol are well defined. The EBCDIC issue is a make or break issue. MongoDB works decidedly with UTDF-8 and I need COBOL to natively view a string as UTF-8. Does the current incarnation of COBOL (and perhaps PL/I) have a native UTF-8 string type. If not, then I will abandon the whole project. I'm doubtless blowing (or something) into the wind again, but this sounds like a place for UTF-EBCDIC. Which is easily translated to and from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8 was just a typo.) Presumably it would be a good start if COBOL could see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings that would live as UTF-8 in the database. Then when COBOL learns to handle UTF-EBCDIC, it could handle the complete UNICODE set. The wire protocol is binary. The UTF-8 requirement for strings in the BSON spec http://bsonspec.org/#/specificationhttp://bsonspec.org/#/**specification http://bsonspec.**org/#/specificationhttp://bsonspec.org/#/specification . I really like the look of BSON. It's like google protocol buffers but more flexible. XML is the pleated khakis of the document markup world. http://www.unicode.org/reports/tr16/http://www.unicode.org/**reports/tr16/ http://www.**unicode.org/reports/tr16/http://www.unicode.org/reports/tr16/ Tony H. --**--** -- 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 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 IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
National literals and the NATIONAL-OF and DISPLAY-OF intrinsic functions are available at least back to version 4.1. The limitation of national literals to 80 characters (however that character is defined in the code page selected by the CODEPAGE compiler option) seems like another poor choice to me. Why is the length of literals so limited? 160 characters for ordinary alphanumeric literals and 80 characters for national literals looks like a compiler lexical scan limitation to me, but I could be wrong about that. Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ze'ev Atlas Sent: Friday, October 25, 2013 12:00 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages? Actually, it looks like there is support to UTF-8: ___ You need to do two steps to convert ASCII or EBCDIC data to UTF-8: Use the function NATIONAL-OF to convert the ASCII or EBCDIC string to a national (UTF-16) string. Use the function DISPLAY-OF to convert the national string to UTF-8. ___ This is from Enterprise COBOL for z/OS Version 5.1 documentation and there is N type. ZA -- 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: Is there currently a way to access MongoDB from z/OS LE languages?
Why do you say there is a need for a C layer here? Even without using Object COBOL you can use JNI directly in COBOL. (It's not great fun, but it is doable.) From: Jantje. jan.moeyers...@gfi.be To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, October 25, 2013 4:33 AM Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages? On Thu, 24 Oct 2013 22:58:05 -0500, John McKown john.archie.mck...@gmail.com wrote: I'm not sure about the following. I'm up late due to ... well, it doesn't matter. But I am wondering if it would be easier to interface MongoDB (on a remote system such as z/Linux) with a z/OS Java routine. And then interface the Java routine with COBOL. I need to read up on the Java - COBOL communication. It may only be for Object COBOL. Java to COBOL and COBOL to Java can be done through JNI. You will need a C layer to glue the two together but you do not neec Object COBOL if you dont want it. Cheers, Jantje. -- 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: Getting the SMF time
On Fri, 25 Oct 2013 10:01:20 -0500, John McKown wrote: If I were in charge (no chance), I would go with exactly TWO different ... While I'm at it, the default TZ in LE and UNIX, if not specifically set, should also be assumed to be the equivalent of what the offset is in the CVT. How would you deal with the matter that (in winter) Colorado and Arizona have identical values of CVTLDTO in the CVT, but Colorado has TZ=MST7MDT and Arizona has TZ=MST7? Rather, since TZ has the greater functionality, I'd advocate the opposite convention: if CVTLDTO is set to some reserved value (e.g. 8X'FF'), TZ as set in the z/OS UNIX profiles should be used for conversion to local time. How about making TZ a special JCL symbol so users in geographically diverse locations could get output timestamped according to their local conventions. All system logs should be timestamped in UTC. ISPF PDS member timestamps should be in UTC. Leap seconds? POSIX screwed up unforgivably and irreparably by writing an internally contradictory specification. Thus: http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xbd_chap04.html The Open Group Base Specifications Issue 7 IEEE Std 1003.1, 2013 Edition Copyright © 2001-2013 The IEEE and The Open Group ..., it is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch. ??? MVS made a halfhearted attempt to do better. How would your proposal handle CVTLSO? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Sources for learing about state of the art Mainframe Virtual and physical tape?
Hi Peter, I hope you will be learning, not learing. ;-) Lizette provided a good list of options. Additional virtual options include: IBM TS7740, VTFM Oracle VSM, VLE Since the subject included physical tape, IBM TS1140 Oracle T1D, 9840D Russell's presentation is a good source. Bear in mind that it's 3 1/2 years old (maybe he has updated it since then). So some things have changed, in particular Bus-Tech was bought by EMC over 3 years ago. HTH. Regards, Mike Baldwin Cartagena Software Limited Your Fast and Flexible Choice Markham, Ontario, Canada Tel.: +1 905-887-0755 Toll-free: 1-888-873-8273 (U.S., Canada) mailto:m...@cartagena.com www.cartagena.com TelTape for z/OS: www.teltape.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
I will look carefully at the Java option and JNI, but my inclination (as an old timer) is to adapt the C driver rather. Working directly with C subroutines from COBOL, without a Java layer seems to me to be more natural, but again, I am an old timer and I do not really know Java. If I need extensive additional functionality, not available in the driver, than that could be a reason to do Java (and learn that stuff at long last; I love working with languages that I don't know.) Can somebody please point me to the documentation of JNI and interfacing Java and COBOL. I did not yet look at the N type and the limitation that have been mentioned here (only 80 characters) would be a make or break. If indeed I cannot reasonably deal with (virtually) unlimited UTF-8 strings then I will not even start the porting project. My time and resources are limited! ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
The compiler limitations are for LITERALS, not for variables. Think VALUE clause, or constant strings MOVEd to a variable. Variable sizes are not any more limited for NATIONAL than for regular DISPLAY alphanumeric, AFAICT. HTH Peter -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ze'ev Atlas Sent: Friday, October 25, 2013 12:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Is there currently a way to access MongoDB from z/OS LE languages? I will look carefully at the Java option and JNI, but my inclination (as an old timer) is to adapt the C driver rather. Working directly with C subroutines from COBOL, without a Java layer seems to me to be more natural, but again, I am an old timer and I do not really know Java. If I need extensive additional functionality, not available in the driver, than that could be a reason to do Java (and learn that stuff at long last; I love working with languages that I don't know.) Can somebody please point me to the documentation of JNI and interfacing Java and COBOL. I did not yet look at the N type and the limitation that have been mentioned here (only 80 characters) would be a make or break. If indeed I cannot reasonably deal with (virtually) unlimited UTF-8 strings then I will not even start the porting project. My time and resources are limited! ZA -- 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: Is there currently a way to access MongoDB from z/OS LE languages?
The compiler limitations are for LITERALS, not for variables. Think VALUE clause, or constant strings MOVEd to a variable. That's good news ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Want your feedback on shell command interface to V2R1 IAZSYMBL
here is a hopefully illustrative example: //SYMTEST JOB (),'KIRK',MSGCLASS=H // EXPORT SYMLIST=(MYSYM) // SET MYSYM='/some/useful/path/name' //SHELL EXEC PGM=COZBATCH # a better BPXBATCH //STDIN DD * set -o pipecurrent # required for: | read ... # get the current JES symbols as shell variables # ... maybe use these to control the script? jessym -s | . /dev/fd0 echo MYSYM=$MYSYM # set some new JES symbols jessym -c DSN1=MY.FOO.IN DSN2=MY.FOO.OUT # submit a job, passing all JES symbols, and get the jobid fromdsn //kirk.sample.jcl(br14) \ | todsn -x symlist(*) //intrdr \ | read x jobid x # JOB JOB submitted echo JOB $jobid submitted # wait for the job to run i=0 while [[ i -le 20 ]]; do lsjes -t -i $jobid | read x jobname x phase x compl # lsjes outputs a line like: #JOB JOBNAME USERID PHASE CLASS RC= if [[ $phase == OUTPUT ]]; then echo JOB $jobname($jobid) completed $compl # grab one of the job's spool files and print it to stdout # ... might also want to grep/sed/process it fromdsn -JES.$jobid.JESJCL break fi let i=i+1 sleep 2 done // Here's the job output written to DD:SYSOUT (the merged stdout/stderr from the shell): MYSYM=/some/useful/path/name fromdsn(KIRK.SAMPLE.JCL(BR14))[N]: 3 records/240 bytes read; 71 bytes written in 0 milliseconds. todsn(INTRDR)[N]: 71 bytes read; 3 records/240 bytes written in 0.885 seconds (80.226 Bytes/sec). JOB JOB00502 submitted JOB BR14(JOB00502) completed RC= fromdsn(KIRK.BR14.JOB00502.D003.JESJCL)[N]: 10 records/835 bytes read; 845 bytes written in 0 milliseconds. 1 //BR14 JOB (),'WOLF',MSGCLASS=H,NOTIFY=SYSUID. JOB00502 IEFC653I SUBSTITUTION JCL - (),'WOLF',MSGCLASS=H,NOTIFY=G1JAVA1 2 // SET DSN1=MY.FOO.INGENERATED STATEMENT 3 //DSN1 EXPORT EXPSET=MY.FOO.IN GENERATED STATEMENT 4 // SET DSN2=MY.FOO.OUT GENERATED STATEMENT 5 //DSN2 EXPORT EXPSET=MY.FOO.OUT GENERATED STATEMENT 6 // SET MYSYM=/some/useful/path/name GENERATED STATEMENT 7 //MYSYMEXPORT EXPSET=/some/useful/path/name GENERATED STATEMENT 8 // EXEC PGM=IEFBR14 9 // CoZBatch[I]: returning rc=exitcode=0 Notice the generated statements above; the JES symbols passed into the submitted job Kirk Wolf Dovetailed Technologies http://dovetail.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting the SMF time
On Fri, Oct 25, 2013 at 8:50 AM, Donald Likens dlik...@infosecinc.com wrote: deleted CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD deleted This returns what looks to me to be a good TODCLOCK TODCLOCK +0 CC208E64 F236F8F4 http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.ieaa900%2Fiea3a9_Description14.htm Now I do a STCKCONV STCKVAL=TODCLOCK,CONVVAL=TMECVTD,DATETYPE=MMDD, + TIMETYPE=DEC It returns: TMECVTD +0 0867 10182013 The time is not correct (the date is). Any ideas on what I am doing wrong? By my calculations the time should be 14:52:00.16. http://pic.dhe.ibm.com/infocenter/zos/v2r1/topic/com.ibm.zos.v2r1.ieaa900/iea3a9_Description14.htm TIMETYPE=DEC returns x'HHMMSSss' so plus 00.000867 seconds. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
OT: From UNIX fortune command, too good not to share
I think that I shall never hear A poem lovelier than beer. The stuff that Joe's Bar has on tap, With golden base and snowy cap. The stuff that I can drink all day Until my mem'ry melts away. Poems are made by fools, I fear But only Schlitz can make a beer. -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: From UNIX fortune command, too good not to share
Admirable sentiments of course, but Kilmer's original contains six rhyming two-line stanzas; and this is short two, has only four, a prosodic disaster. 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
Re: OT: From UNIX fortune command, too good not to share
Hi John, Do tell. Have you the full text? It is Friday, after all. BTW, this is the first time I've ever seen the word prosodic outside of a dictionary. Thanks! BobL -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John Gilmore Sent: Friday, October 25, 2013 1:12 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: OT: From UNIX fortune command, too good not to share [ External ] Admirable sentiments of course, but Kilmer's original contains six rhyming two-line stanzas; and this is short two, has only four, a prosodic disaster. 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 This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: From UNIX fortune command, too good not to share
For the full text google: Kilmer trees --jg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: GDG question
At 21:25 -0700 on 10/24/2013, Phil Smith wrote about GDG question: If a jobstep runs with a DD for a GDG that's got DISP=MOD, and the jobstep reads but never tries to write the file, does a new, zero-length GDG get created? I'm of course hoping the answer is No. The only time a new GDG dataset is created is when you use a DSN of GDG(+x) [GDG(-x) are older generations]. In your case you are asking for GDG(0) so you can update it without creating a new generation. Note however that DISP=MOD is the same as DISP=OLD so far as that jobstep having exclusive access to the dataset (so no other job step can read it). The difference between DISP=OLD and DISP=MOD for an existent dataset is writes to the former erase the data (ie: Only the data you write will be there) while the later leaves the old data and adds the new to the end of the dataset. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Getting the SMF time
On Fri, 25 Oct 2013 08:50:53 -0500, Donald Likens wrote: I already convert the SMF time into human time by using arithmetic but I am having a problem with the calculation and I am attempting to use the ASM macros to convert the time. Here is what I am doing: * CREATE TODDATE MVC SMFDATE,SMF2DTE MVI SMFDATE,X'20' L R2,SMFDATE R2 X'20YYDDDS' SRL R2,4R2 X'020YYDDD' STR2,CVDATE CVDATE XL4 X'020YYDDD' MVC CVZERO,ZERO CONVTOD CONVVAL=CVTD,TODVAL=TODCLOCK,DATETYPE=DDD * SET TIME L R2,TODTIME A R2,SMF2TME STR2,TODTIME If you use DATETYPE=YYDDD instead, you can replace the 5 instructions from MVC to ST with this: MVC CVTD+8(4),SMF2DTE If you use TIMETYPE=BIN and add this instruction before CONVTOD: MVC CVTD(4),SMF2TME then you can eliminate the L,A, and ST instructions after CONVTOD. Also, you might get the result that you are expecting. Bill -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Is it possible to write an exit to add DEFER to a VTAPE allocation?
We have some job steps that use ICETOOL to copy 50 DASD or VTAPE datasets to two VTAPE datasets. We have not been able to convince the owner of the job to add DEFER to the allocation. So when a couple of these jobs run at the same time, we run out of our 512 VTAPE drives. Holds up other jobs, or HSM Migrate / Recalls until the step ends and releases the drives. I am hoping we can get these tapes drives down to just those actually being used at one moment (assuming ICETOOL does one file at a time instead of simultaneous coping of multiple files). -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: John Dvorak explains why the z is doomed (indirectly)
In 048f01cecf45$e90428a0$bb0c79e0$@net, on 10/22/2013 at 09:44 AM, Gerhard Adam gada...@charter.net said: Let's also remember that in the good old days you paid for every manual, You paid for Sxxx- manuals; Gxxx- manuals were free in reasonable quantities. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Rexx compiler used for System Automation and Netview?
In 5266b6e3.1060...@valley.net, on 10/22/2013 at 01:33 PM, Gerhard Postpischil gerh...@valley.net said: The compiler is handy for syntax checking and other error detection that the interpreter won't find until your program has been in production for years g That's one of the things that's nice about OREXX on OS/2; it tokenizes the entire program, and catches syntax errors up front. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Command output not displayed on Console
In c11ded818b17214792b97fba28712bed17203d4...@jer-email1.jer.ad.malam.com, on 10/22/2013 at 11:21 AM, ÔÒÚ ß ÓßÚ gad...@malam.com said: What do i have to change for the output to appear. MSGROUT? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Clemson Univ. Data Center Tour (1980)
In 5265a0bc.90...@clemson.edu, on 10/21/2013 at 05:46 PM, Jim Blalock ca...@clemson.edu said: The unit-record gear was all IBM. No one did it better :-) With some exceptions. I recall a lot of stacker problems on the 3211, and the 3525 was an unmitigated disaster. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: From UNIX fortune command, too good not to share
At 15:33 -0400 on 10/25/2013, John Gilmore wrote about Re: OT: From UNIX fortune command, too good not to share: For the full text google: Kilmer trees --jg Interestingly I live in Suffern NY right across the border from Mahwah NJ where there is a High School named for him. The Wikipedia article on him says he lived there when he wrote Trees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: OT: From UNIX fortune command, too good not to share
ot even more - Suffern has some tough ICE Hockey teams LOL From: Robert A. Rosenberg hal9...@panix.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 10/25/2013 05:04 PM Subject:Re: OT: From UNIX fortune command, too good not to share Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU At 15:33 -0400 on 10/25/2013, John Gilmore wrote about Re: OT: From UNIX fortune command, too good not to share: For the full text google: Kilmer trees --jg Interestingly I live in Suffern NY right across the border from Mahwah NJ where there is a High School named for him. The Wikipedia article on him says he lived there when he wrote Trees. -- 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 IPL Issue
In 20131023075515.07f678e2041c928bd4cca...@gmx.net, on 10/23/2013 at 07:55 AM, nitz-...@gmx.net nitz-...@gmx.net said: 'we have always used a real console for NIP, we want to keep it', They consider a TN3270 session from a PC to be a real console? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: old manuals
In 4851323882589608.wa.jerry.ellislibertymutual@listserv.ua.edu, on 10/23/2013 at 09:35 AM, J Ellis jerry.el...@libertymutual.com said: I'm looking for this manual: Did you look in bitsavers? S/390® I/O Interface Channel to Channel Control Unit OEMI What's the forms code and what channels does it describe? If it's only BT and ESCON then I can understand why it's gone. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is it possible to write an exit to add DEFER to a VTAPE allocation?
How about an allocation exit that abends or flushes the job after the 10th tape drive is allocated unless the job is in class Q. Then make the Q initiator available 0300-0400 on alternate odd-numbered Sundays. No one should be allowed to consume resources they don't need out of laziness, especially when it causes other problems. However, if you must accommodate the diva, JES2 exit 6 can alter the encoded JCL. We use it to update the parameters of an OUTPUT statement so users are not affected by a printer replacement. This included changing the length of some parameters. It should work for DD cards also. :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Mike Schwab :: Sent: Friday, October 25, 2013 1:55 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Is it possible to write an exit to add DEFER to a VTAPE :: allocation? :: :: We have some job steps that use ICETOOL to copy 50 DASD or VTAPE :: datasets to two VTAPE datasets. We have not been able to convince the :: owner of the job to add DEFER to the allocation. So when a couple of :: these jobs run at the same time, we run out of our 512 VTAPE drives. :: Holds up other jobs, or HSM Migrate / Recalls until the step ends and :: releases the drives. I am hoping we can get these tapes drives down :: to just those actually being used at one moment (assuming ICETOOL does :: one file at a time instead of simultaneous coping of multiple files). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DISPLAY TCPIP,,NETSTAT help
Happy Friday, CROSS-POSTED to IBMTCP-L and IBM-MAIN. I think it's been a long week. I tried two commands with MAX=* and got different results. COnn and SOCKets look like they can take the same parameters. My Global Configuration Information: says MaxRecs: 100. If the report output is truncated, the n value specifies the number of records for which all output lines are successfully displayed. D TCPIP,TCPDFLT,N,CO,CLI=VPS*,FORM=LONG,MAX=* EZD0101I NETSTAT CS V1R13 TCPDFLT 313 USER ID CONN STATE . 3 OF 9 RECORDS DISPLAYED D TCPIP,TCPDFLT,N,SOCK,CLI=VPS*,FORM=LONG,MAX=* EZD0101I NETSTAT CS V1R13 TCPDFLT 425 SOCKETS INTERFACE STATUS: .. 7 OF 7 RECORDS DISPLAYED END OF THE REPORT Q). If my global is 100, and my max is * (or some large number), why does SOCK show 7 of 7, and CO only shows 3 of 9? I'd like to see all 9 of 9. I don't think I need FORM= to be able to use MAX=. Thank you, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: old manuals
In 0e2a01cecfff$76c47640$644d62c0$@mindspring.com, on 10/23/2013 at 07:52 AM, Lizette Koehler stars...@mindspring.com said: Jerry is looking for the CCWs and sense codes. CCW's and sense codes for what device? Or is he looking for information on self-decribing devices? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation problem with LMCOPY
In 9159676159882753.wa.paulgboulderaim@listserv.ua.edu, on 10/23/2013 at 11:44 AM, Paul Gilmartin paulgboul...@aim.com said: What's this ampersand business? Assuming this is clist correct apostrophes Assuming that it is REXX. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Allocation problem with LMCOPY
On Fri, 25 Oct 2013 18:04:20 -0500, Shmuel Metz (Seymour J.) wrote: on 10/23/2013 at 11:44 AM, Paul Gilmartin paulgboul...@aim.com said: What's this ampersand business? Assuming this is clist I considered that possibility but deemed the presence of the address instruction a refutation. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is it possible to write an exit to add DEFER to a VTAPE allocation?
Adding defer will only delay the tape mount until OPEN, the drives are still allocated. If you want to dynamically add defer you can use IEFUJI and flip SCTDEFER in the SIOTs. Dan -Original Message- From: Mike Schwab Sent: Friday, October 25, 2013 4:55 PM Newsgroups: bit.listserv.ibm-main Subject: Is it possible to write an exit to add DEFER to a VTAPE allocation? We have some job steps that use ICETOOL to copy 50 DASD or VTAPE datasets to two VTAPE datasets. We have not been able to convince the owner of the job to add DEFER to the allocation. So when a couple of these jobs run at the same time, we run out of our 512 VTAPE drives. Holds up other jobs, or HSM Migrate / Recalls until the step ends and releases the drives. I am hoping we can get these tapes drives down to just those actually being used at one moment (assuming ICETOOL does one file at a time instead of simultaneous coping of multiple files). -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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: Is it possible to write an exit to add DEFER to a VTAPE allocation?
Mike Schwab wrote: We have some job steps that use ICETOOL to copy 50 DASD or VTAPE datasets to two VTAPE datasets. We have not been able to convince the owner of the job to add DEFER to the allocation. So when a couple of these jobs run at the same time, we run out of our 512 VTAPE drives. Holds up other jobs, or HSM Migrate / Recalls until the step ends and releases the drives. I am hoping we can get these tapes drives down to just those actually being used at one moment (assuming ICETOOL does one file at a time instead of simultaneous coping of multiple files). I think you want UNIT=AFF= rather than DEFER. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Command output not displayed on Console
On Tue, 22 Oct 2013 11:21:16 +0300, ��� �� ��� gad...@malam.com wrote: Hi, I added a few consoles, and the operators are complaining that the output from $DI is not displayed on the console. When I issue the $DI command I see this in the syslog, but nothing is displayed on the console: T064 0290 $DI STC09092 0290 $DI,CLASS,STATUS,JOBNAME INTERNAL 0090 $HASP892 INIT(1)CLASS=KQ1B,STATUS=INACTIVE INTERNAL 0090 $HASP892 INIT(2)CLASS=Q,STATUS=INACTIVE -snip- Based on SYSLOG, the command was issued by some console named T064 (EMCS, maybe SDSF or some other tool). T064 cannot be one of your MCS consoles (all of which are unnamed, given that they bear their console ids) based on your D C command below: IEE889I 07.33.49 CONSOLE DISPLAY 689 MSG: CURR=0LIM=9000 RPLY:CURR=0LIM=50 SYS=BOIA PFK=28 CONSOLE/ALTID --- SPECIFICATIONS --- SYSLOG COND=H AUTH=CMDS NBUF=0UD=N ROUTCDE=ALL 01/02 01 COND=M AUTH=MASTER NBUF=0UD=Y 04A0 AREA=Z MFORM=J BOIA DEL=RRTME=1 RNUM=16 SEG=20CON=N USE=FC LEVEL=ALL PFKTAB=PFKTAB1 ROUTCDE=ALL MONITOR=JOBNAMES,SESS 09/10 09 COND=A AUTH=ALL NBUF=0UD=N 1000 AREA=Z MFORM=J BOIA DEL=RRTME=1 RNUM=16 SEG=20CON=N USE=FC LEVEL=ALL PFKTAB=PFKTAB1 ROUTCDE=ALL MONITOR=JOBNAMES,SESS 10/09 10 COND=A AUTH=ALL NBUF=0UD=N 1001 AREA=Z MFORM=J BOIA DEL=RD RTME=1 RNUM=18 SEG=9 CON=N USE=FC LEVEL=ALL PFKTAB=PFKTAB1 ROUTCDE=ALL MONITOR=JOBNAMES,SESS You could probably figure out what's happening by GTF tracing the pertinent SSI control blocks (SSIB, SSOB, SSCM) before/after the command processing SSI (code 10). I'm pretty sure that IBM documents how to do this somewhere because who the frack screwed up my control blocks is a frequent SSI problem. Forensically, it would appear that someone(s) on the SSI are changing the command text (augmenting the command) and changing the issuing console id to zero (I don't believe you can alter the console name to INTERNAL). It's not clear to me why you'd expect a command response to show up on a different console from the one issuing the command (other than by MSGROUT, as pointed out elsewhere). A way that you might capitalize on this behavior is to assign the INTIDS attribute to the consoles where you want the output to go. Using INTIDS says, I want all messages routed to console id 0 to come to here. Have a look here (mind any wrap): http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2g370/3.4.7?ACTION=MATCHESREQUEST=intidsTYPE=FUZZYSHELF=EZ2ZO10I Scott Fagen Chief Architect - System z CA Technologies -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DISPLAY TCPIP,,NETSTAT help
Rather - you might like to try this free tool from IBM The EZANS Tool has now been made a real tool (don't worry - it is still for free). You can go to the following web site to down-load the latest version, which supports z/OS releases from V1R4 through V1R12. The official name of the tool now is: The IBM z/OS Communications Server Network Utility Assistant http://www.ibm.com/support/docview.wss?uid=swg24029203 Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Hansen, Dave L - Eagan, MN Sent: Friday, October 25, 2013 2:40 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: DISPLAY TCPIP,,NETSTAT help Happy Friday, CROSS-POSTED to IBMTCP-L and IBM-MAIN. I think it's been a long week. I tried two commands with MAX=* and got different results. COnn and SOCKets look like they can take the same parameters. My Global Configuration Information: says MaxRecs: 100. If the report output is truncated, the n value specifies the number of records for which all output lines are successfully displayed. D TCPIP,TCPDFLT,N,CO,CLI=VPS*,FORM=LONG,MAX=* EZD0101I NETSTAT CS V1R13 TCPDFLT 313 USER ID CONN STATE . 3 OF 9 RECORDS DISPLAYED D TCPIP,TCPDFLT,N,SOCK,CLI=VPS*,FORM=LONG,MAX=* EZD0101I NETSTAT CS V1R13 TCPDFLT 425 SOCKETS INTERFACE STATUS: .. 7 OF 7 RECORDS DISPLAYED END OF THE REPORT Q). If my global is 100, and my max is * (or some large number), why does SOCK show 7 of 7, and CO only shows 3 of 9? I'd like to see all 9 of 9. I don't think I need FORM= to be able to use MAX=. Thank you, Dave -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: z/OS IPL Issue
On 10/23/2013 3:19 PM, Thomas Conley wrote: On 10/23/2013 3:47 PM, John McKown wrote: Curiosity question: Why do you need multiple remote I3270C sessions per LPAR? If we ever go to z/OS 2.1 (iffy), we would only use it for IPLing. We use SMCS consoles via TN3270 for other consoles, beyond the Visara ones in the NOC (computer room adjunct). We often have multiple people looking at the console messages via the Java app on the HMC, especially when we're having a problem shutting down a system after TSO is gone or starting a system up before TSO is available. My good friend the distinguished gentleman from California is correct, this is a serious shortcoming in the Integrated 3270 console support. This example was well very illustrated using real life, every day situations by my friend and distinguished colleague from the great state of New York. I will yield him the remainder of my time.. :-) -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
On 25/10/2013 11:13 PM, Rob Schramm wrote: Not sure how to respond.. on the one hand you have an excellent point. One the other hand.. Google jdbc and mongodb.. as well as there being a jdbc link on the mongodb page in addition to the mongodb java connectors. Doesn't really change my intent ... Grab the mongodb java database driver.. (how does jmdbc driver sound???) and couple it with the cobol application code. I understood your original intent Rob. I was just sounding off about JDBC drivers for non-relational data bases. I've never quite grasped why there are so many SQL adapters for non-relational data bases. Even IMS has a Java SQL interface with ODBC and I just don't get it. Is SQL really that much better then native APIs? In the case of your typical key/value data store surely get/set is easier than SELECT FROM WHERE/UPDATE SET IN etc. Rob On Oct 25, 2013 3:03 AM, David Crayford dcrayf...@gmail.com wrote: On 25/10/2013 1:51 PM, Rob Schramm wrote: With a JDBC driver and a bit of JAVA code..you could use the COBOL/JAVA procedure BCDBATCH to help tie the two together. Did a quick scan and there appear to be at least few JDBC drivers. I'm scratching my head as to why a JDBC driver is useful with a NoSQL data base which has a very specific API. Why not just use the MongoDB Java API? Does JDBC provide some kind of value add? Rob Rob Schramm Senior Systems Consultant Imperium Group On Fri, Oct 25, 2013 at 1:18 AM, David Crayford dcrayf...@gmail.com wrote: On 25/10/2013 12:28 PM, Tony Harminc wrote: On 24 October 2013 23:49, Ze'ev Atlas zatl...@yahoo.com wrote: About a previous post, the endianess should not be a big issue to deal with once the two sides of the protocol are well defined. The EBCDIC issue is a make or break issue. MongoDB works decidedly with UTDF-8 and I need COBOL to natively view a string as UTF-8. Does the current incarnation of COBOL (and perhaps PL/I) have a native UTF-8 string type. If not, then I will abandon the whole project. I'm doubtless blowing (or something) into the wind again, but this sounds like a place for UTF-EBCDIC. Which is easily translated to and from UTF-8 if that's what goes on the wire. (I'm assuming your UTDF-8 was just a typo.) Presumably it would be a good start if COBOL could see and manipulate the subset of UTF-EBCDIC that is EBCDIC strings that would live as UTF-8 in the database. Then when COBOL learns to handle UTF-EBCDIC, it could handle the complete UNICODE set. The wire protocol is binary. The UTF-8 requirement for strings in the BSON spec http://bsonspec.org/#/specificationhttp://bsonspec.org/#/**specification http://bsonspec.**org/#/specificationhttp://bsonspec.org/#/specification . I really like the look of BSON. It's like google protocol buffers but more flexible. XML is the pleated khakis of the document markup world. http://www.unicode.org/reports/tr16/http://www.unicode.org/**reports/tr16/ http://www.**unicode.org/reports/tr16/http://www.unicode.org/reports/tr16/ Tony H. --**--** -- 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 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 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
