jBASE

[Road Jogger]

Hi,

 

We are currently on jBASE 5.0 minor 21 on AIX 5.3.... T24 release is R8....

 

In jBASE documentation for the STATUS command if used on a file.variable, return the PART NUMBERS of part files belonging to a distributed file in a multivalue list....

 

(TEXT from jBASE documentation)

 

1 Current position in the file Offset in bytes from beginning of file
2 End of file reached 1 if EOF, 0 if not.
3 Error accessing file 1 if error, 0 if not.
4 Number of bytes available to read
5 File mode Permissions (in octal) 6 File size in bytes.
7 Number of hard links 0 if no links. Where applicable else 0
8 O/S User ID. ID based on the user name and domain of the user a jBASE pseudo user.
9 O/S Group ID.
STATUS statement
10 I-node number; Unique ID of file on file system
11 Device on which i-node resides Number of device. The value is an internally calculated value on
Windows NT.
12 Device for special character or block Number of device.
13 Time of last access in internal format
14 Date of last access in internal format.
15 Time of last modification in internal format
16 Date of last modification in internal format.
17 Time and date of last status change in internal format.
18 Date of last status change in internal format.
19 Number of bytes left in output queue (applicable to terminals only)
20 { }
21 jBASE File types j3, j4, jPLUS
22 jBASE File types j3, j4, jPLUS
23 jBASE File types j3, j4, jPLUS
24 Part numbers of part files belonging to a distributed file multivalued list

 

Now, in reality, this doesnt happen.... I have a distributed file, and when I use the STATUS command to get the PART NUMBERS, it return ZERO.... see below....

 

LIST-DISTRIB F.CUST.ECB
Partitioning Algorithm is USER Subroutine 'CUST.PARTNO'
Part file 'F.CUST.P1.ECB', part number 1
Part file 'F.CUST.P2.ECB', part number 2
Part file 'F.CUST.P3.ECB', part number 3
Part file 'F.CUST.P4.ECB', part number 4
Part file 'F.CUST.P5.ECB', part number 5
Part file 'F.CUST.P6.ECB', part number 6
Part file 'F.CUST.P7.ECB', part number 7
Part file 'F.CUST.P8.ECB', part number 8
Part file 'F.CUST.P9.ECB', part number 9

 

& when I use the STATUS command on the above file, like the code is ....

 

OPEN "F.CUST.ECB" TO F.CUST.ECB THEN

     YFILE.STAT = ''

      STATUS YFILE.STAT FROM F.CUST.ECB THEN

           PRINT YFILE.STAT<24>

      END

END

 

The output returned is ZERO.....

 

Definitely this file is distributed.... and I need to know the PART FILE NUMBERS if the file is distributed???

 

Any ideas

 

Thanks,

N

 

[Jim Idle]

STATUS is something pretty crummy inherited from Prime via Universe I think. However, if it is documented that it should work, then it is clearly a bug and you should report it to TEMENOS. There is nothing we can do here to fix it J Do you get any of the information back at all?

Also, why is it that you think you need to know about the part numbers? Perhaps you are asking the wrong question ;-)

 

Jim

 

 

 

--
Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines
 
IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24
 
To post, send email to jB...@googlegroups.com
To unsubscribe, send email to jBASE-un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/jBASE?hl=en

[Daniel Klein]

It's a bug in the documentation as fields 24 thru 26 have always returned a hard-coded zero since the inception of the 'STATUS' command in jBASE.

The only way to obtain this information is to parse the output from the LIST-DISTRIB command.

Dan

[Road Jogger]

My question is RIGHT.... I need the part numbers because of some specific local developments... Anyways thanks for the info.... will raise it as an bug to temenos...

 

Thanks,

N.

[Daniel Klein]

I'm allergic to "Cos I Said So" arguments.

What are these "specific local developments" ?

It seems to me that the question is WRONG until this is explained.

Dan

To unsubscribe from this group, send email to jbase+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.

[VK]

Hi,
I'm also quite curious... how a local development can be dependent on
whether we have a distributed file or a regular one? What next? It
will need to know how many cores are in CPU? :))

Probably SELECTing from a particular part to make SELECT faster?
Please supply more info.

VK

On Mar 20, 11:51 pm, Daniel Klein <danielklei...@gmail.com> wrote:
> I'm allergic to "Cos I Said So" arguments.
>
> What are these "specific local developments" ?
>
> It seems to me that the question is WRONG until this is explained.
>
> Dan
>

> On Sat, Mar 20, 2010 at 6:10 AM, Road Jogger <roadjog...@gmail.com> wrote:
> > My question is RIGHT.... I need the part numbers because of some specific
> > local developments... Anyways thanks for the info.... will raise it as an
> > bug to temenos...
>
> > Thanks,
> > N.
>

> > On Thu, Mar 18, 2010 at 5:48 PM, Jim Idle <j...@temporal-wave.com> wrote:
>
> >>  STATUS is something pretty crummy inherited from Prime via Universe I
> >> think. However, if it is documented that it should work, then it is clearly
> >> a bug and you should report it to TEMENOS. There is nothing we can do here
> >> to fix it J Do you get any of the information back at all?
>
> >> Also, why is it that you think you need to know about the part numbers?
> >> Perhaps you are asking the wrong question ;-)
>
> >> Jim
>

> >> *From:* jb...@googlegroups.com [mailto:jb...@googlegroups.com] *On Behalf
> >> Of *Road Jogger
> >> *Sent:* Thursday, March 18, 2010 8:04 AM
> >> *To:* jB...@googlegroups.com
> >> *Subject:* jBASE

> >> *24 Part numbers of part files belonging to a distributed file
> >> multivalued list*

[Road Jogger]

Dan,

 

Dont make your problem as other's problem.... either the people who wrote the jBASE documentation are very very stupid who have just copied the Universe documentation without even actually testing it....

 

Even If I tell you the "SO CALLED LOCAL DEVELOPMENTS", I dont think you will understand & care about.... so why all the fuss...

 

N.

[Daniel Klein]

Cool your jets, Jack!

 

Being of an inquisitive nature, I was naturally curious about the reasons anyone would need to know what the part numbers are. Apparently, there are none.

 

If you could provide a substantial business reason then that would be grounds for improving the product to match the documentation ;-)

 

Dan

[Neil at C A Software]

Why the hostility “Road Jogger”?

 

It is always helpful to provide an explanation of what you are trying to achieve and why, so that the jBASE development and support teams (as well as other contributors to this support list e.g. JimI) can assess if the route you are trying can be circumvented or approached from a different direction.  Whether people will understand your development is equally irrelevant (as well as presumptuous with the calibre of people you are addressing), at least you have explained and they can ask you to elaborate.

 

If you continue with the hostility and rudeness then no-one is going to help you!  The one thing you can guarantee is that the people who frequent this list are keen to help with problems and advice.

 

Neil.

[FFT...@aol.com]

Can't you just "reach underneath" the environment and grab the part numbers from the directory level ?

I haven't worked with jBase but that's what I used to do with Universe on Unix which also used part numbers in distributed files.  It's not a complex task, provided jbase can execute a query to the operating system.  And then parse the string.

Will

[FFT...@aol.com]

In a message dated 3/22/2010 10:05:43 AM Pacific Daylight Time, daniel...@gmail.com writes:

Being of an inquisitive nature, I was naturally curious about the reasons anyone would need to know what the part numbers are. Apparently, there are none.

IIRC, we did this when... something.. foggy memory.
I *think* we're were trying to list the "files" by largest file first.  Logical files which need to collate the part numbers into one "file" and yet we couldn't figure out a way to determine the "size" of a file without actually scanning it.  In Unix however you can find the size (or at least the block's assigned) and roll the parts together into one "file" and then output File X is 800 Megabytes...

The business point was, that in certain situations "We're running out of disk!" we needed to concentrate on pruning the largest files first.

Will "Does that work for you? Or should I hit you another time" Johnson

[Road Jogger]

There is no hostility/ Neil... but became quite upset with Dan's comments.... Will explain the requirements by end of this week.... got something more imp. to do.... in live....