Re: z/OS IPL Issue
No. Master console *was* a thing from MCS world. During NIP there weren't master console - just console, only one. And there was (and still is) an order which console will be used from devices available. First on the list taken (if available), but it has nothing to do with master. Nowadays there is no master console in MCS even. -- Radoslaw Skorupka Lodz, Poland W dniu 2013-10-23 22:11, efinnell15 pisze: It used to be that if the Master was unavailable, the first interrupt from a defined consol became the Master.(Meatball hoagie in tape shop taught us this). In a message dated 10/23/13 14:36:28 Central Daylight Time, d10j...@us.ibm.com writes: If no valid NIP console has been found, we will use the system console (a.k.a. Opeating System Messages on the HMC) to IPL the system. -- 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.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.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: PL/1 and z/OS 2.1
Hi Gary Yes, There are many many calls to MQCONN, MQOPEN, etc in the PL/1 for MVS programs. Regards and thanks Paul -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gary Jacek Sent: Wednesday, October 23, 2013 10:00 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/1 and z/OS 2.1 Do you use MQ Series with your old PL/1 modules? Gary -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Lizette Koehler Sent: October 23, 2013 06:23 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: PL/1 and z/OS 2.1 Paul, Here is a link to the PL/1 lifecycle http://www-01.ibm.com/software/support/lifecycle/index_e.html So what kind of investment in PL/1 is involved. All applications are developed in PL/1 Up to 50% applications are developed in PL/1 All CICS transactions are PL/1 This type of information could be helpful with your question. Any upgrade will be depended on how vested you are in the compiler and how time critical your applications are. z/OS V2.1 and CICS TS 5.1 are fairly new. I am not sure that there are many shops using these levels of software at this time. You may also, if you have not done so, join the CICS Newsgroup and ask this question over there as well. http://www.listserv.uga.edu/archives/cics-l.html Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Beesley, Paul Sent: Wednesday, October 23, 2013 6:09 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: PL/1 and z/OS 2.1 Hi I am aware that PL/1 for MVS 1.1.1 is unsupported (and probably has been for some time) but is anybody using it on z/OS 2.1, or CICS 5.1 for that matter? We have a customer who is reluctant to upgrade to Enterprise PL/1 or whatever the most recent flavour is called. Regards and thanks Paul -- 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: Issue with the REORG of BDAM datasets
Thanks gentleman ..That was it . A standalone REORG needs space to hold the new index and CA suggested us to do ASYNCH REORG . Thank you ! On Wednesday, October 23, 2013 8:07 AM, Roger Steyn roger.st...@yahoo.com wrote: Greetings , Recently , we had a problem during the REORG of SAR index file . It was observed that the index file utilization increases abnormally while the REORG job runs and comes down once the job completes. In the mean while , if the utilization crosses 100 % , the job fails and SAR task cannot be restarted unless more space is added .The index file is of DSORG=DA . I 'm interested to know what exactly happens during the REORG of BDAM datasets .I am not sure if this is a normal behavior . I have already raised this query to CA , but also thought of sharing it over here . Anybody had this problem before with CA view (formerly SAR ) ? Thanks in Advance, Roger -- 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: Allocation problem with LMCOPY
You are right , I was thinking of the case when you use the format
'LMINIT DATAID(LMID) DATASET('dsn') ENQ(SHR)'
Here it allocates a ISPn dd.
Best Regards
Thomas Berg
___
Thomas Berg Specialist zOS\RQM\IT Delivery SWEDBANK AB (Publ)
-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
Behalf Of Paul Gilmartin
Sent: Wednesday, October 23, 2013 10:49 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Allocation problem with LMCOPY
On 2013-10-23 10:55, Thomas Berg wrote:
-Original Message-
From: Paul Gilmartin
Sent: Wednesday, October 23, 2013 6:45 PM
On Wed, 23 Oct 2013 09:21:25 -0700, Jon Perryman wrote:
1. LMINIT allocates a new DD. The DDNAME is placed in the variable
you specified in DATAID.
LMINIT do really create a new allocation with a ddname in the format
ISPn, e g ISP12345.
Presumably it frees it a LMFREE.
Not by my experiment. The EXEC:
/* Rexx */ signal on novalue; /*
*/
trace R
RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
'dsn('userid()'.TEMP.LMTEST' ,
'dsorg(PS) recfm(V,B) lrecl(137) msg(WTP)' )
address 'ISPEXEC'
'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )
if RC==0 then do
call GetIt
'LMOPEN DATAID('LMID') OPTION(OUTPUT)'
call PutIt
end
'LMFREE DATAID('LMID')'
exit( RC )
GetIt:
address 'TSO'
RC = outtrap(line.,*,NOCONCAT)
'LISTALC STATUS SYSNAMES'
return( RC )
PutIt:
do I = 1 to line.0
LL = line.I
'LMPUT DATAID('LMID') MODE(INVAR) DATALOC(LL)' ,
'DATALEN('length( line.I )')' 'NOBSCAN'
trace N
end I
return( RC )
/* * */
... runs with output:
5 *-* RC = BPXWDYN( 'alloc rtddn(DDX) rtvol(VLX) new delete' ,
'dsn('userid()'.TEMP.LMTEST' ,'dsorg(PS) recfm(V,B) lrec
l(137) msg(WTP)' )
0
9 *-* address 'ISPEXEC'
10 *-* 'LMINIT DATAID(LMID) DDNAME('DDX') ENQ(SHR)'
LMINIT DATAID(LMID) DDNAME(SYS00048) ENQ(SHR)
11 *-* say value( 'DDX' ) value( 'VLX' ) value( 'LMID' )
SYS00048 WORK02 ISR00023
SYS00048 WORK02 ISR00023
...
and when I VIEW the content of TEMP.LMTEST, the only DDNAME allocated to
that data set is the SYS00048 allocated by BPXWDYN.
-- gil
--
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
Thanks. I am so used to being the _only_ person in our _very small_ shop who does IPLs that it never occurred that the person doing the IPL or shutdown would need a helper. Unfortunately, one of the other people here who will (1%) occasionally IPL tends to just punch it out if the shutdown doesn't complete in a reasonable time. Which I why I prefer to do the IPLs. On Wed, Oct 23, 2013 at 5:19 PM, Thomas Conley pinnc...@rochester.rr.comwrote: 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. Regards, Tom Conley --**--**-- 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: z/OS IPL Issue
On Wed, 23 Oct 2013 21:54:54 -0500, John McDowell jmcd...@gmail.com wrote: I agree that the inability to share the Integrated 3270 among multiple concurrent sessions is unfortunate and that it would be a useful enhancement to list that restriction. Off the top of my head I can see that the ownership of the keyboard will need to be resolved in some way, that is only one session should be allowed to provide keyboard inputs (i.e. cursor movement, attention keys, etc.). Otherwise each session could be fighting with the other about what is being done :-( I don't think this problem is insurmountable and in fact I can think of a couple of different design approaches that could be used to solve it. Anyone who has used one of the Windows based conferencing tools has seen how this can be resolved. I run into that sometimes now with fellow sysprogs (usually not operations) when IPLing LPARs during a maintenance window. Not a huge deal. We either see two people are entering keystrokes or it ends up as an invalid command / reply if someone hits the enter key before we notice. The shared consoles are via CA Automation Point, but also use AF Remote for this. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com ITIL v3 Foundation Certified Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html Systems Programming expert at http://search390.techtarget.com/ateExperts/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
DB2 v9-v10 problem
Environment z/OS 1.11, DB2 v9.1, CICS TS 4.1 is being migrated to z/OS 1.13, DB2 v10.1, CICS TS 4.2 (DB2 in Compatibility Mode) One CICS transaction expected strange behavior: much more CPU used for open cursor operation. Acces path wasn't changed. It seems DB2 lost ability to read index in both ways (during MI/MX access) and read and sort more data than it should. Any clue? Anyone experienced similar problem? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: DB2 v9-v10 problem
This would be better asked on the IDUG.ORG forum On Thursday, October 24, 2013, R.S. r.skoru...@bremultibank.com.pl wrote: Environment z/OS 1.11, DB2 v9.1, CICS TS 4.1 is being migrated to z/OS 1.13, DB2 v10.1, CICS TS 4.2 (DB2 in Compatibility Mode) One CICS transaction expected strange behavior: much more CPU used for open cursor operation. Acces path wasn't changed. It seems DB2 lost ability to read index in both ways (during MI/MX access) and read and sort more data than it should. Any clue? Anyone experienced similar problem? -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając 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 authorised 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. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- 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: Allocation problem with LMCOPY
On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote: This will also fix the INIT issue that if a JOB Step has a DISP=OLD with further steps as DISP=SHR, the dataset remains exclusively held until the last DISP=SHR step ends (since INIT can not downgrade the EXC ENQ to the SHR ENQ used by DISP=SHR to allow other jobs access to the dataset). This has been announced as a long-awaited feature of z/OS 2.1. I don't know how it plays with DYNALLOC. -- gil -- 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
As long as you accept a complete line at a time, like multiple SDSF operator sessions, it should work, unless two people happen to issue the same command and it causes problems. On Thu, Oct 24, 2013 at 11:28 AM, John McDowell jmcd...@gmail.com wrote: Mark, I understand what you are saying, the unintentional interleaving of multiple user inputs, is something you can accept/overcome. This is one possible resolution of allowing multiple concurrent uses of the Integrated 3270, I personally favor a model of one writer/multiple readers such is often employed in the various screen sharing technologies found in many conferencing solutions. (Note: I'm guessing the specific examples you offer are not for the Integrated 3270 but your essential point remains the same.) The only question in my mind is how sophisticated a mechanism is needed to pass the baton (e.g. become the one writer). My initial thought is to keep it simple, the first session is the writer, all subsequent sessions are readers, the current writer can pass the baton to any reader. If there is no inter-session awareness then the writer can simply lay down the baton (e.g. surrender the write privilege) and any reader can then pick it up. I'm sure there are other models that could be adopted but the key point that I think we all agree on is that lifting the current restriction that prevents multiple concurrent accessors of the Integrated 3270 is very desirable. John McDowell -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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
Is there currently a way to access MongoDB from z/OS LE languages?
Hi all Is there currently a way to access MongoDB from z/OS LE languages? 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?
On 25/10/2013 10:04 AM, Ze'ev Atlas wrote: Hi all Is there currently a way to access MongoDB from z/OS LE languages? It should be simple enough to build a client. There are many http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing MongoDB running off the mainframe. I'm interested to know why you would want to do that? Porting MongoDB to z/OS is non-trivial as it requires a JavaScript engine, either V8 or SpiderMonkey. Porting either of those is a huge amount of work, although it would be fantastic if somebody could. It requires writing a JIT compiler, so I'm sure IBM have to tech from Java to do that. The current crop of next gen dynamic scripting language JITs like V8 JavaScript or LuaJIT are as fast as Java and not too far off C, and dirt easy to write code in. ZA -- 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?
On 25/10/2013 10:29 AM, Ze'ev Atlas wrote: Assuming I use my experience in porting Open Source C libraries to the mainframe and import the MongoDB C driver and compile it successfully, my main issue would then be, as usual, the pesky EBCDIC. When working on the PCRE library, there was already a full EBCDIC implementation, but there is obviously no joy like that in MongoDB. EBCDIC may not be your only problem! What about endianess? I suggest you study the wire protocol if you are serious *http://docs.mongodb.org/meta-driver/latest/legacy/mongodb-wire-protocol/.* My question would be, I guess (I am not even sure I express it in the correct terminology), is there a way to tell an LE application (mainly COBOL) to use ASCII or UTF-8 in a native way, or alternatively, to present the ASCII code in EBCDIC. http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.cbcux01%2Fascii.htm ZA -- 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?
It should be simple enough to build a client. There are many http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing MongoDB running off the mainframe. I'm interested to know why you would want to do that? I have no intention on porting the whole engine because I understand the difficulties, but allowing COBOL to access MongoDB on some MongoDB cluster is not different (conceptually) from accessing any other remote database. 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?
EBCDIC may not be your only problem! What about endianess? I suggest you study the wire protocol if you are serious thank you for pointing me to the right direction. I will look at the documents you've mentioned about both, EBCDIC and endianess and see if it it worth it. 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?
On 25/10/2013 10:58 AM, Ze'ev Atlas wrote: It should be simple enough to build a client. There are many http://docs.mongodb.org/ecosystem/drivers/. Of course, that's for accessing MongoDB running off the mainframe. I'm interested to know why you would want to do that? I have no intention on porting the whole engine because I understand the difficulties, but allowing COBOL to access MongoDB on some MongoDB cluster is not different (conceptually) from accessing any other remote database. Interesting concept. I'm not aware of any previous requirement for a mainframe COBOL program to access a data base running on a different platform. Just for fun maybe but certainly not in production. It would be very interesting to see how a intrinsically constrained language like COBOL would deal with the dynamic nature of Mongos JSON like document objects. It's not much fun accessing Mongo in C let alone COBOL. ZA -- 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?
It's not much fun accessing Mongo in C let alone COBOL. Agree My language of choice is Perl which flaws with that stuff and I am working on my JavaScript skills. However, what drives me is frustration. Whenever I do a mainframe project, I see how much I miss the other side's features and then I look how to bring those features in. I may need to invent a way to represent complex key value structures in COBOL which is a challenge on its own (unless somebody has already done it.) The simplest solution would be a two dimensional table of Z type strings, but that would not allow in a simple way for hierarchies. I guess I'll have to develop a type and the functionality to handle it. 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. ZA -- 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
At 14:24 -0500 on 10/24/2013, Paul Gilmartin wrote about Re: Allocation problem with LMCOPY: On Thu, 24 Oct 2013 15:12:39 -0400, Robert A. Rosenberg wrote: This will also fix the INIT issue that if a JOB Step has a DISP=OLD with further steps as DISP=SHR, the dataset remains exclusively held until the last DISP=SHR step ends (since INIT can not downgrade the EXC ENQ to the SHR ENQ used by DISP=SHR to allow other jobs access to the dataset). This has been announced as a long-awaited feature of z/OS 2.1. I don't know how it plays with DYNALLOC. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN If the INIT can release the DISP=OLD (ie: EXC) ENQ at the end of the last step where there a need for the DISP=OLD while allowing subsequent steps where the dataset is declared as DISP=SHR to have a SHR ENQ, then this TO ME implies that ENQ support has been fixed to allow an EXC ENQ to be converted to a SHR ENQ and allow the ENQ chain to then allow subsequent ENQs in the chain to be satisfied so until the next EXC in the chain is encountered or the chain end is reached (IOW: If the first ENQ on the chain after the EXC being converted to SHR is a SHR, then it and all the following waiting SHR ENQs will be satisfied just like what occurs if the EXC ENQ is released via a DEQ). -- 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'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. Anyway, it's just a weird thought from a person who is sleep deprived. On Thu, Oct 24, 2013 at 10:49 PM, Ze'ev Atlas zatl...@yahoo.com wrote: It's not much fun accessing Mongo in C let alone COBOL. Agree My language of choice is Perl which flaws with that stuff and I am working on my JavaScript skills. However, what drives me is frustration. Whenever I do a mainframe project, I see how much I miss the other side's features and then I look how to bring those features in. I may need to invent a way to represent complex key value structures in COBOL which is a challenge on its own (unless somebody has already done it.) The simplest solution would be a two dimensional table of Z type strings, but that would not allow in a simple way for hierarchies. I guess I'll have to develop a type and the functionality to handle it. 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. ZA -- 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?
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 -- 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 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. 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
GDG question
Apologies for the naïve question, but I spent some time Googling and reading and didn't find a clear answer to this. We have a data set that gets fetched from the network and changes occasionally. I'd like to untie this update from normal operation-that is, on the off-chance that the network is down at the precise instant that we check for the data set, I'd like things to continue operating. So I'm thinking that if we cache a copy of the data set on disk (the contents aren't sensitive), we could try to fetch; if we can't fetch, we shrug and continue; if we can, we compare the data read with the existing data (there's a timestamp) and only rewrite if it's changed. 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. A GDG seems like it would work great for this: the number of generations could be defined as low as two, so the update would write the other copy, and the next time one of the tasks tries to read it, it would get the newer one. So here's my question (aside from the obvious one of Am I missing something above that makes this dumb): 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. Thanks, -- ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
NY Metro NaSPA Chapter Meeting: Tuesday, 29 October 2013
he next meeting of the NY Metro NaSPA Chapter will be on Tuesday, 29 October, 2013, in room 1219 at the IBM Building at 590 Madison Avenue, New York City, from 10:00 AM until 4:30 PM. Sessions for the day include: A Perspective on System z Capacity Delivery - Past and Future, Bob Rogers, IBM Distinguished Engineer, Retired, Consulting Engineer, Trident Services Corporations, governments and other large enterprises always have a nearly insatiable demand for more mainframe computing power. Over recent decades advances in chip technology and processor design have met the lion's share of this demand. However, we are entering an era when hardware advancement is most likely not going to continue at the same pace. So now is a perfect time to review other techniques for growing capacity like multiprocessing and Sysplex clustering and also prognosticate on how we can continue to grow mainframe capacity without big bumps from chip technology. Your future will include increasing the number of processors in your z/OS images and possibly clustering images with Parallel Sysplex. You'll also have to be ready for some entirely new technologies that will be introduced into your mainframe environment. About the speaker: Bob Rogers worked on mainframe system software for 43 years at IBM before retiring as a Distinguished Engineer in 2012. He started with IBM as a computer operator in 1969. After receiving a B.A. in Mathematics from Marist College in 1971, he became a computer programmer at the Poughkeepsie Programming Center, where he worked on the OS/370 operating system. Bob continued to work on mainframe operating system development for his entire career at IBM. He contributed to the transitions to XA-370 and ESA/370, and was lead software designer for the transition to the 64-bit z/Architecture. He implemented the support for single z/OS images with more than 16 CPUs and was a lead designer of the z/OS support for the zAAP and zIIP specialty engines. Today's z/OS implements dozens of his design ideas. His last assignment at IBM was to foster greater synergy between System z hardware and software. Bob has been a popular speaker at the System z Technical University and other venues for many years. Currently, he is doing some work with Trident Services, Inc., a software vendors whose software is also sold by IBM. He’s also a technical editor and occasional writer for IBM Systems Magazine. z/OS V2.1 Overview, Greg Daynes, Senior Technical Staff Member, IBM This session will discuss new facilities and features in z/OS V2.1 that affect system programmers and application developers. It will cover highlights of functions for scalability and performance, availability, management, security, application development, and usability. About the speaker: Greg Daynes is a Senior Technical Staff Member and the z/OS Installation Deployment Architect in IBM at Poughkeepsie, New York. His current responsibilities include designing solutions for z/OS software acquisition, software installation, hardware and software migrations, software deployment, and as well as implementing maintenance strategies. Greg is a frequent speaker at SHARE and the IBM System z Technical University (formerly zExpo). The Care and Feeding of Couple Datasets, Mark Brooks, IBM This session provides a comprehensive overview and detailed discussion of couple data sets (CDS). We will cover basics such as: What is a CDS? Why do I need one? How is it used? How do I create one? How do I get the sysplex to use it? W will discuss in detail the sysplex couple data set, the various function couple data sets, and explain terminology such as primary CDS, alternate CDS, PSWITCH, active policy, administrative policy, format utility, and policy utility. There will also be a discussion of best practices and real world mistakes seen by the XCF level 2 service team with an eye towards helping you avoid them in your shop (and how to recover if possible). Those that are new to sysplex should walk away with a firm grasp of all that is needed to confidently deal with couple data sets in their sysplex. Those with experience will find value as well -- even if most of the basics are well known -- as they should walk away with a more detailed understanding that should enable them to better ensure that couple data sets in their sysplex are configured and managed in a way that avoids unnecessary risk. After all, mistakes with a CDS can lead to a sysplex wide outage! About the speaker: Mark Brooks is a Senior Programmer in Poughkeepsie, New York. For more
Re: Want your feedback on shell command interface to V2R1 IAZSYMBL
Oh yea.. I guess if I paid more attention to the topic... I would have seen that. It is funny that everyone starts to gravitate towards problems around the same time. Been working some on RDz.. BPX_SHAREAS and SPAWN_SCRIPT have recently become very interesting to me. I have to admit that the whole thing is starting to take on a slightly voodoo-istic shadings. The best is the BPX_SHAREAS=MUST which is more likely to be MOSTLY. VBG... some of this stuff just makes me laugh. Definitely would have failed the RFC writing rules. Rob Rob Schramm Senior Systems Consultant Imperium Group On Wed, Oct 23, 2013 at 10:47 PM, Kirk Wolf k...@dovetail.com wrote: Rob, I think that EZACFSM1 is for MVS System symbols, where as IAZSYMBL is JES System Symbols (introduced in V2R1). Kirk Wolf Dovetailed Technologies http://dovetail.com On Wed, Oct 23, 2013 at 8:59 PM, Rob Schramm rob.schr...@gmail.com wrote: Kirk, Isn't there a utility (EZACFSM1) provided by Comm Serv to already do what you are talking about? Although.. EZACFSM1 is probably not as dynamic as you are looking for. TCPIP config uses it for fixing up symbol values. Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Wed, Oct 23, 2013 at 8:23 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 23 Oct 2013 14:09:45 -0500, Kirk Wolf wrote: (*Note*: in the following examples, shell input is bold and follows . Also: you need set -o pipecurrent when piping jessym output into read or . ) ... * set -o pipecurrent * * jessym A | read -r myvar* * echo $myvar* B Now, you've got me started. From: Title: z/OS V1R13.0 UNIX System Services Command Reference Document Number: SA22-7802-14 SHEX Shell execution environments ... Each command in a pipeline (such as command | command) runs in a child shell environment, unless the pipecurrent shell option is in effect. If pipecurrent is set on (with set -o pipecurrent or set -P), then the last command of the pipeline is executed in the current shell environment. ... Doesn't this mean that the left list of a pipeline will always run in a child shell environment (therefore a separate address space?), regardless of pipecurrent, and that JES symbols of the parent shell will not be available in that child shell environment? -- gil -- 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?
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/#/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/ 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
Re: GDG question
Phil, AFAIK, the whole GDG assignment only happens once.. during initial creation. MODing will change the size of the data set.. not the GVoo number(s). With SMS a new GDG entry gets rolled in at step end. Most everything you need to know is in Chapter 29. Processing Generation Data Groups of the DFSMS Using Data Sets book. The link is http://pic.dhe.ibm.com/infocenter/zos/v1r13/index.jsp?topic=%2Fcom.ibm.zos.r13.idad400%2Fch14.htm The only thing I didn't see in there is a detailed explanation of the GDG roll-over when counting past 9 generations. There are a couple of old APARS that go into great detail on how the process works and what to expect. Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Fri, Oct 25, 2013 at 12:25 AM, Phil Smith p...@voltage.com wrote: Apologies for the naïve question, but I spent some time Googling and reading and didn't find a clear answer to this. We have a data set that gets fetched from the network and changes occasionally. I'd like to untie this update from normal operation-that is, on the off-chance that the network is down at the precise instant that we check for the data set, I'd like things to continue operating. So I'm thinking that if we cache a copy of the data set on disk (the contents aren't sensitive), we could try to fetch; if we can't fetch, we shrug and continue; if we can, we compare the data read with the existing data (there's a timestamp) and only rewrite if it's changed. 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. A GDG seems like it would work great for this: the number of generations could be defined as low as two, so the update would write the other copy, and the next time one of the tasks tries to read it, it would get the newer one. So here's my question (aside from the obvious one of Am I missing something above that makes this dumb): 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. Thanks, -- ...phsiii -- 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?
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. 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
