I have a report I've been running in a Pick environment for years without
problems. The data, using ECLTYPE P on UniData, looks like:
[UNIDATA]
SORT BANKBOOK WITH PLANTNOS = "9800""9900" AND WITH YRMO = "200411" BY
PLANTNOS PLANTNOS TOTAL CURRBAL 22:45:48 Feb 07 2006 1
BANKBOOK... PLNT# CURR BA
Thanks Guys, 9001 does the trick.
If anyone has list of the undocumented system values it would a very
interesting read.
Re
andy
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of James Cowell
Sent: 07 February 2006 12:48
To: u2-users@listserver.u2ug.org
Su
> Anybody ever run into a problem with SB+ being unable to read
directory files, Type 1 & 19?
No problems here, SB+ 5.0.4/UniVerse 10.0.7/AIX 5.1. Type 1 and Type
19 files, a mixed bag of delimiters (think of a character between 0
and 255 - it's probably been used).
On Universe, I would expect yes.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan
Fitzgerald
Sent: Tuesday, February 07, 2006 7:20 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] SB & directory files
This would be AIX. Would question marks cause
Charles,
we dont run transaction logging.
THe has been corrupted 3 times in 3 months.
I didnt take a copy of the indexinfocus problems but will look again when
its up and running.
I am guessing that its the edi routine thats causing this problem but the
error message suggests that and ther
Stew,
we have a large named common in an include but no inline comments and
this hasnt been modified for years
jak
- Original Message -
From: "Mitchell, Stewart" <[EMAIL PROTECTED]>
To:
Sent: Wednesday, February 08, 2006 12:23 PM
Subject: RE: [U2] SYS.MESSAGE file being corrupted
Kevin,
thats correct.
You replace the file with a copy and all is ok.
I sent 3 copies of the corrupted file to IBM and they confirmed that it is
Universe writing to the file but i dont know why.
jak
- Original Message -
From: "Kevin King" <[EMAIL PROTECTED]>
To:
Sent: Wednesday,
This would be AIX. Would question marks cause this? Thanks.
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
That's the UV message file, right? You're actually seeing the message
"corrupted"? Or do you have a program that is doing like a
STOP 201
??
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Yes. Under Windows particularly if the item ID has a "*" or any other
forbidden filename characters in the key, reads and writes will fail.
Actually, I remember writes failing, but at the moment I'm not
particularly certain reads failed also because I couldn't get any data
in the file.
-Origi
> From: John Kent
> Has anyone experienced the above and have an explanation
Maybe. Except SYS.MESSAGE wasn't being corrupted, but rather text from
SYS.MESSAGE was corrupting other data files.
It this what you mean?
I think I have the dubious honour of finding it first (at least IBM
seemed to n
Bob,
i dont have anything as sophisticated as that.
I am opening up the file in the main program and passing it through to the
subroutine.
I dont understand how a file pointer could end up referencing SYS.MESSAGE
though when the application software never references it.
Thanks for the su
JAK,
Further to BobW's post, do you have INCLUDE statements in the program with
in-line comments attached ie
$INCLUDE INC.FILE INC.RECORD ;* Comment here
As this will corrupt the line numbers, that is you need to add the number of
include lines with in-line comments to the line number reported
Hi John,
In our system, we have a subroutine that opens files and places the file
handle information in a dimensioned array. When the subroutine is
called, it first checks the array to see if it's already been opened.
If it has, the handle information is passed back without having done an
actual
Anybody ever run into a problem with SB+ being unable to read directory
files, Type 1 & 19?
---
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
Bob/Kevin
the platform is Windows 2000 and its a dynamic file passed in through a
subroutine.
ie CALL *SUB(FILE1,FILE2)
I have checked for it being clobbered and we do not refer to SYS.MESSAGE so
i cant see how this could happen
I have tried writing test programs to get the same error me
1) What is the platform - *nix or Windows?
2) If *nix, what are the owner/group/permissions on the file? Proper
for all users of this program?
3) Is the file distributed?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of John Kent
Sent: Tuesday, February 07
I've not run into this before but from what you have listed, I'd be
looking at what file the write attempt is being performed on. If it's
not the SYS.MESSAGE file, which it probably is not, then I'd be looking
at how the file open's are being done. I'd suspect the file handle
variable being used
Has anyone experienced the above and have an explanation
I have seen some postings at indexinfocus but no resolution.
There doesnt appear to be any 3rd part software involved and the application
software doesnt ever reference this file but its occurred 3 times in the last
3 months.
The quick fix
Hello Andy,
Please give us a call at FusionWare. FusionWare purchased all the Data
Access products from GA Express and is a new company with the original
people from Liberty Integration. Now that's quite a trail to follow.
I guess what I am saying is we have the technology and people to help
you
Symeon Breen wrote on 02/07/2006 09:37:24 AM:
> Seems you can do this in universe using system but perhaps not unidata
SYSTEM(49) does this for UniData. If "call stack" means the command-line
stack history, that's in SYSTEM(52).
Tim Snyder
Consulting I/T Specialist , U2 Professional Services
> It's possible to access the call stack from debugger using
> the T command, anybody know if it's also possible to access
> it from a basic program.
Subject: [UV] SYSTEM(9001) tells you what program you are in & where you
came from!
From:Stevenson, Charles ([EMAIL PROTECTED])
> From: Brian Leach
> Whilst we're on the subject, has anyone compiled a list of
> these 'undocumented' system() values?
I've been stashing away the SYSTEM()-related emails from this list for a
few years now.
Maybe its time to compile them and submit it as a paper for U2UG.
I'll at least find m
In UD I believe it's SYSTEM(49), although I'm prepared to stand corrected by
someone that actually uses it :)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Symeon Breen
Sent: 07 February 2006 14:37
To: u2-users@listserver.u2ug.org
Subject: Re: [U2] CAll S
Hi andy,
Seems you can do this in universe using system but perhaps not unidata
Rgds
Symeon
On 2/7/06, Brian Leach <[EMAIL PROTECTED]> wrote:
>
> Whilst we're on the subject, has anyone compiled a list of these
> 'undocumented' system() values?
>
> Brian
>
> > -Original Message-
> > From:
Well, just off the top of my head, from stuff I've been working on at
home...
help = variable
HELP = constant
Help = Class or Method
These naming conventions are optional, but they are conventions. And that's
just in python.
--
Dave Walker
"The only reason some people get lost in thought is becau
Whilst we're on the subject, has anyone compiled a list of these
'undocumented' system() values?
Brian
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of James Cowell
> Sent: 07 February 2006 11:48
> To: u2-users@listserver.u2ug.org
> Subject: RE: [U
I once wrote a "wraparound" to the savelist commands which datestamps
the lists on creation and use. Also allows the user to flag a savelist
as one that should not be overwritten or deleted. A purge program
allows them to purge out savelists that are no longer necessary or
haven't been access
In UV there is an undocumented SYSTEM value, 9001, that you can query to get
your own call stack.
CRT SYSTEM(9001)
It's stored in multi-valued format though so you'll need to do a bit of
processing to make it look pretty.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTE
In universe I get it like this:
CMD = 'PORT.STATUS PORT ':@USER.NO:' LAYER.STACK '
EXECUTE CMD CAPTURING TEXT
-- mats
Andrew Lakeland wrote:
It's possible to access the call stack from debugger using the T command,
anybody know if it's also possible to access it
It's possible to access the call stack from debugger using the T command,
anybody know if it's also possible to access it from a basic program.
Searched the manuals for "call stack" but all references point to the
debugger.
Ta
Andy
---
u2-users mailing list
u2-users@listserver.u2ug.org
To
craig.cauchi wrote:
> Is there a more efficent driver for extracting data from
> Unidata via SQL/ODBC?
>
> Has anyone tried the UNIOLEB driver?
Among standard FileOpen, ReadU, and dynamic array operations, mv.NET has
the ability to work with MV data using commands that are familiar to SQL
users
32 matches
Mail list logo
