Re: Rexx performance question
On 1/12/07, Peter Rothman [EMAIL PROTECTED] wrote: Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. The EXECCOMM interface is known to be slow. With GLOBALV you only use it once to set the variable, with the Pipeline you need 2 for the same thing. I would expect that to be slow. Depending on the number of Rexx variables present and involved, you may gain back some performance using 'rexxvars' to retrieve all variables and have a 'lookup' stage select the ones to use. If there's enough variables to copy that this makes a difference, then I assume they contain the data your subroutine works on. It is often not hard to make the subroutine in a pipe stage and pass the data through the pipeline rather than the Rexx variables. But the most efficient approach is of course to keep the data in the pipeline entirely. Rob
I am out of the Office until 1/22/2007
I will be out of the office starting 01/13/2007 and will not return until 01/20/2007. I am out of the office until 1/22/2007. I am not checking e-mail or voice messages during that time.
Re: Rexx performance question
The GLOBALV solution often also requires two calls to EXECCOMM: GLOBALV PUT in the calling exec and GLOBALV GET in the callee If the variables contain one word only, one can indeed save a call to EXECCOM: 'GLOBALV SET V1' content 'V2' content But, in such cases one can also pass the variables as arguments to the callee. In my PRFGUI package, this technique is extensively used. The caller: 'EXEC PRFGD PLOT' files ',', WorkWithTrd Spec407Bug UserVarsFnd NodeVarsFnd TracePipe chartid',', DtStringFromCharPtr DtStringToBuffer DtStringAppend DtObjectDelete, DtEventNotify DtValueSet DtValueGet DtTableCount DtTableQuery, hCnChanClo hCnChanRun hCnEdChMsg hCnEdChMsgC hCnLyChan',', Days2plot red cyan cyan2 yellow yellow2 gddmSticky, ',' hCnLsFlDisa, Note that I insert some separator character (a comma above) when a preceeding variable can be empty or when the contents can be more than 1 word. Needless to say that the corresponding PARSE ARG in the callee must have an indentical template. -- Kris Buelens, IBM Belgium, VM customer support 2007/1/13, Rob van der Heij [EMAIL PROTECTED]: On 1/12/07, Peter Rothman [EMAIL PROTECTED] wrote: Besides a lot of 'steam lining' I thought I would be 'clever' and changed the GLOBALVs to 'PIPE var VarName 1 | var VarName'. The EXECCOMM interface is known to be slow. With GLOBALV you only use it once to set the variable, with the Pipeline you need 2 for the same thing. I would expect that to be slow. Depending on the number of Rexx variables present and involved, you may gain back some performance using 'rexxvars' to retrieve all variables and have a 'lookup' stage select the ones to use. If there's enough variables to copy that this makes a difference, then I assume they contain the data your subroutine works on. It is often not hard to make the subroutine in a pipe stage and pass the data through the pipeline rather than the Rexx variables. But the most efficient approach is of course to keep the data in the pipeline entirely. Rob
Re: IBMLink 2000 Finding ESO levels
Rob van der Heij wrote: Come on Sir. You're just repeating hearsay nonsense arguments. Yours is almost as good as the one to replace the VM Toolsrun-based employee directory by LDAP because the VM solution required updates to be applied to all copies of the data spread over multiple VM system I believe IBM set back the clock 10 years by migrating off their VM applications internally. for some strange reason or another, there is a ldap redbook that has reference to some webpage of ours at garlic.com precursor to TOOLSRUN for employee directory was CJNTEL ... posting with old email from 1981 proposing a CJNTEL-based public key infrastructure http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network other posts with old email (from 70s early 80s) mentioning CJNTEL (and maybe some TOOLSRUN) http://www.garlic.com/~lynn/2006w.html#16 intersection between autolog command and cmsback (more history) http://www.garlic.com/~lynn/2006w.html#25 To RISC or not to RISC http://www.garlic.com/~lynn/2006w.html#44 more secure communication over the network http://www.garlic.com/~lynn/2006y.html#7 Securing financial transactions a high priority for 2007 http://www.garlic.com/~lynn/2007b.html#7 information utility then there was line told top executives that the internal network had to be converted to SNA ... because PROFS was an VTAM application and would otherwise stop working http://www.garlic.com/~lynn/2006x.html#7 vmshare concurrent with CJNTEL was the online telephone directory ... recently mentioned here http://www.garlic.com/~lynn/2006v.html#32 Effi[ci]ency of branch table vs individual compare branch ... now, of course, LDAP ... stands for lightweight directory access protocol ... a morphing of DAP/X.500 ... part of the ISO/OSI suite of protocols. The first time I remember hearing about X.500 was at ACM SIGMOD conference ... i think '92 at santa clara convention center ... it was described as a bunch of networking engineers trying to re-invent 1960s database technology. these day, most LDAPs are layered on some RDBMS technology. for other drift, lots of past posts on original relational/sql, System/R ... all developed on VM http://www.garlic.com/~lynn/subtopic.html#systemr
z/VM 5.2 conversion IP problem
I'm in the mist of converting from z/VM 5.1 to z/VM 5.2 and having an IP problem. The VM stack is connected to a vswitch. And as far as the VM side is concerned, all is well, (FTP, PING, TN3270, etc). My, more modern VSE guests (2.5 and above) are connected to the vswitch and all seems to be well. However, my old VSE systems (2.3) are VCTCA routed thru z/VM and I have no connection what so ever. I know what the problem is, it is me. G Actually, I couldn't just take my ZVMV5R10 TCPIP statements and put them on the newer system. I had to rewrite many of them. The only test systems I had to test with when I was testing z/VM 5.2 second level were newer VSE systems connected via vswitch. From VSE (TCP/IP 1.5B) I get: 0016: IPL395E Senseid I/O error on receive port, Cuu:0982 Sns:40 LinkID: LINK02 0016: IPL391E Unable to Initialize CTC Adapter, Cuu:0982 Linkid: LINK02 They are coupled: AR 0015 CTCA 0982 3088 COUPLED TO TCPIP0923 SUBCHANNEL = 0003 AR 0015 CTCA 0983 3088 COUPLED TO TCPIP0922 SUBCHANNEL = 0004 I have Sunday and Monday to straighten out this problem before I back out. I'm toying with the idea of running the old z/VM 5.1 stack on z/VM 5.2. I can't ping from VM to VSE. I can't ping from VSE to VM. Pieces of the VM config file: ; The following configuration is for St. Louis City Hall - NEWESA4 DEVICE NEWESA4 CTC 0922 LINK LNEWESA4 CTC0 NEWESA4 HOME 205.235.227.74 255.255.255.000 QDIO1 ; (End HOME Address information) ; -- ; -- ; Primary interface Definition ; -- PRIMARYINTERFACE QDIO1 ; -- GATEWAY ; Network Subnet First Link MTU ; Address MaskHop Name Size ; - --- --- - 205.235.227 255.255.255.0 = QDIO11500 192.168.099.24 HOST = LNEWESA4 1500 DEFAULTNET 205.235.227.41 QDIO11500 ; (End GATEWAY Static Routing information) START NEWESA4 With the VM startup, I got the same errors I've normally had. Of course, they may be more serious now. 15:03:21 DTCPAR123I LINE 231: NO IPV4 HOME ADDRESS FOR DEVICE NEWESA4 15:03:21 DTCPDO069I ADDBSDINFO: NO IPV4 HOME ADDRESS FOR LINK LNEWESA4 15:03:21 DTCPAR106I DEVICE:NEWESA4, TYPE:CTC 15:03:21 DTCPAR107ILINK: LNEWESA4, TYPE: CTC, NETWORK NUMBER: 0 15:03:21 DTCPDO076I192.168.99.24DIRECTLINK NAME: LNEWESA4 NAME: NEWESA4, DEV TYPE: CTC MAX 1500 HOST ROUTE Obviously, I'm at a loss right now. Thanks Tom Duerbusch THD Consulting
Re: http://www.vm.ibm.com/
There was a problem outside of IBM's networks which cut off www.vm.ibm.co m from the outside world. It was resolved Friday night. B.
