Yes, it was really bizarre. I pulled out my support call and found I was wrong about the versions - it was broken in 6.0.2 and fixed after (at least on Windows).
Here are my testing notes: The only pattern I've found is that if I use SBClient and start a GUI session then use "0" to get the command prompt the list.readu will work. If I start a windows telnet session at this time the list.readu will also work in that session. The SBClient session will stop working if I return to the menu (MM) and go to the TCL prompt (/TCL) whether or not a command is run. The windows telnet will continue to work until I close it and start a new session. If I have SBClient shutdown and create two windows telnet sessions the list.readu will not work. It looks like *something* is getting set with the SBClient session. Didn't get a lot of detail back from IBM something about a structure not being initialized properly or at the right time. I did get a patched .exe and .dll that resolved the problem. It was actually a fix for a problem with selects.... Colin >-----Original Message----- >From: Kevin King > >That sounds a little bizarre. Do you recall any details of >why this might have been so? > >-----Original Message----- >From: Alfke, Colin > >Ooops, I thing I forgot to mention. On some versions of UniData >(5.2.4?) doing a /TCL in SB+ will cause UniData to not output >information with LIST.READU. I don't recall if there is also a >problem with GETREADU() - plus it's already in an array so you >don't have to trim and parse >(truncated) data (unless you use the DETAIL modifier).. > >This was corrected in 6.0.2. > >Hth >Colin Alfke >Calgary, Canada ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
