I had the error in my paging screen...
111 - MAXIMUM PAGING SEQUENCE NUMBER EXCEEDED
help!!!
my version of proiv
Kernel Version 4.6000, Revision 2.0.1 (Jan 17, 00)
Click the link below to see the new game I'm developing!
Proiv paging
Started by
siobi
, Sep 21 2004 10:38 AM
26 replies to this topic
#2
Rob Donovan
-
- Admin
-
- 1,652 posts
rob@proivrc.com
- Gender:Male
- Location:Spain
Posted 21 September 2004 - 10:49 AM
Hi,
There is a maximum number of records you can have in a paging screen, and its 32767.
That error means the paging screen is trying to display too many records.
HTHs,
Rob D.
There is a maximum number of records you can have in a paging screen, and its 32767.
That error means the paging screen is trying to display too many records.
HTHs,
Rob D.
#3
Chris Mackenzie
-
- Members
-
- 372 posts
ProIV Guru
- Gender:Male
- Location:Bristol, United Kingdom
Posted 21 September 2004 - 03:45 PM
Anyone fancy making a change request to P4, reminding them 64 bits are common these days?
The content and views expressed in this message are those
of the poster and do not represent those of any organisation.
of the poster and do not represent those of any organisation.
#6
Rob Donovan
-
- Admin
-
- 1,652 posts
rob@proivrc.com
- Gender:Male
- Location:Spain
Posted 21 September 2004 - 09:55 PM
Me too...
And more than 255 logics, and 999 lines, and the total function size should be made bigger, since its fairly easy to blow the size of a function, with just a few large filedefs and arrays. Since most of us are coding apps for machines with have more that 16K memory, it should be unlimmited.
Although, any paging screen with 32000+ records need to be thought about, because it cant be very usable by the user...
Rob.
And more than 255 logics, and 999 lines, and the total function size should be made bigger, since its fairly easy to blow the size of a function, with just a few large filedefs and arrays. Since most of us are coding apps for machines with have more that 16K memory, it should be unlimmited.
Although, any paging screen with 32000+ records need to be thought about, because it cant be very usable by the user...
Rob.
#8
Rob Donovan
-
- Admin
-
- 1,652 posts
rob@proivrc.com
- Gender:Male
- Location:Spain
Posted 22 September 2004 - 08:17 AM
Only happened a few times.
If you code clearly, and have plenty of comments, its not too bad
Oh, and while were at it, more than 999 lines in FDESC would also help, since lots of people use this for versioning a function and 999 runs out in busy functions...
Rob D.
If you code clearly, and have plenty of comments, its not too bad
Oh, and while were at it, more than 999 lines in FDESC would also help, since lots of people use this for versioning a function and 999 runs out in busy functions...
Rob D.
#9
Tony Waszkiewicz
-
- Members
-
- 174 posts
Expert
- Gender:Male
- Location:London, United Kingdom
Posted 22 September 2004 - 09:56 AM
Guys,
I asked proiv to remove these silly limitations at the last two European User Groups.
Things like all the above and 8 character file/function names...
Apparently this would be difficult, so they are not going to do it <_<
regards
I asked proiv to remove these silly limitations at the last two European User Groups.
Things like all the above and 8 character file/function names...
Apparently this would be difficult, so they are not going to do it <_<
regards
Edited by Tony Waszkiewicz, 22 September 2004 - 09:56 AM.
#11
Lewis Mccabe
-
- Members
-
- 455 posts
ProIV Guru
- Gender:Male
- Location:Sarasota, Florida
Posted 22 September 2004 - 03:18 PM
We have been asking that the size limits of functions, logic count per function, and logic line count per function to be increased for years. At one of the VAR meetings a few years ago, the discussion actually got pretty heated (and with some major VARS in attendance) but to no avail. As Tony says, it must be a ton of work.
Our major problem is with the 255 logic limit per function. Each global logic uses one of those slots, so if you have more than a few globals in a function, you can lower your ceiling quite quickly. For us, this is compounded by the fact that we often have global logics calling other global logics.
If we were asked today what limits we would like to see eased, I would ask for them to increase the function max size, and increase the 255 logic count per function. Others of you obviously bump into the other limits, but those are ours.
PRO-IV's argument, which does carry some weight, is that with the advent of global functions and the ability to call them from just about anywhere, you should be coding using smaller called functions. This approach though does not always lead to the best design and/or performance.
I doubt we will see much movement on this by PRO-IV in the near future unless we, as a unit, make a good case for it. Remember though, PRO-IV has finite resources. Is making these changes the best use of those resources? If they embark on these changes it would mean something else, possibly more important, would move down on the list. Unless we know what is on that list, we are shooting in the dark. I would like to know what features they are working on now, and what they are planning for the future.
Anyone at PRO-IV willing to give us a short and long term heads up on the next release and beyond?
Our major problem is with the 255 logic limit per function. Each global logic uses one of those slots, so if you have more than a few globals in a function, you can lower your ceiling quite quickly. For us, this is compounded by the fact that we often have global logics calling other global logics.
If we were asked today what limits we would like to see eased, I would ask for them to increase the function max size, and increase the 255 logic count per function. Others of you obviously bump into the other limits, but those are ours.
PRO-IV's argument, which does carry some weight, is that with the advent of global functions and the ability to call them from just about anywhere, you should be coding using smaller called functions. This approach though does not always lead to the best design and/or performance.
I doubt we will see much movement on this by PRO-IV in the near future unless we, as a unit, make a good case for it. Remember though, PRO-IV has finite resources. Is making these changes the best use of those resources? If they embark on these changes it would mean something else, possibly more important, would move down on the list. Unless we know what is on that list, we are shooting in the dark. I would like to know what features they are working on now, and what they are planning for the future.
Anyone at PRO-IV willing to give us a short and long term heads up on the next release and beyond?
Edited by Lewis Mccabe, 22 September 2004 - 03:19 PM.
#12
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 22 September 2004 - 04:06 PM
When it was first developed, the core of ProIV was hand coded in assembler. When it was converted to 'C' (many years ago now!) it was just run through an assembler to 'C' converter. So the core of the code is undocumented and not particularly meaningful.
To remove the basic limits they'd effectively have to create a ProIV clone that emulated all the subtle interactions that go back to the year dot to make it backwards compatible.
Some years ago, when Sushil was more interested (and probably still remembered something about it!) MDIS were trying to get him to assist him to work it all out.
If it was a simple fix then it would have been done ages ago! That's also why the basic structure and limitations of the language haven't had major changes.
To remove the basic limits they'd effectively have to create a ProIV clone that emulated all the subtle interactions that go back to the year dot to make it backwards compatible.
Some years ago, when Sushil was more interested (and probably still remembered something about it!) MDIS were trying to get him to assist him to work it all out.
If it was a simple fix then it would have been done ages ago! That's also why the basic structure and limitations of the language haven't had major changes.
#13
Chris Pepper
-
- Members
-
- 369 posts
ProIV Guru
- Gender:Male
- Location:United Kingdom
Posted 22 September 2004 - 04:19 PM
On the number of logic lines... we've found the system has a workspace issue when an individual logic (or global logic) gets past a certain size. As a rule of thumb we reckon anyting more than about 800 lines long (depending on comments & code density) stands a good chance of failing to gen.
Since we have some fairly complex server code & calculations we're frequently bumping into these limits!
Since we have some fairly complex server code & calculations we're frequently bumping into these limits!
#14
Tony Waszkiewicz
-
- Members
-
- 174 posts
Expert
- Gender:Male
- Location:London, United Kingdom
Posted 22 September 2004 - 04:28 PM
Great, so ,
"... the core of the code is undocumented and not particularly meaningful..."
IMHO if they cannot easily make some simple changes what chance is there of catching up with other development languages?
tell me again why are we using this
regards
"... the core of the code is undocumented and not particularly meaningful..."
IMHO if they cannot easily make some simple changes what chance is there of catching up with other development languages?
tell me again why are we using this
regards
#15
Lewis Mccabe
-
- Members
-
- 455 posts
ProIV Guru
- Gender:Male
- Location:Sarasota, Florida
Posted 22 September 2004 - 07:18 PM
Chris,
This is the first I have heard of the assembler conversion not being well documented. It does make sense why they have been loathe to make what we feel are necessary changes to PRO-IV. They had to have made that conversion back in the 80's when they first came out with version 1.5. So hopefully much of the work since then is clean and documented. How big an albatross is that old converted code? I'm sure no one will freely admit. I have to say, it does make me nervous knowing the source is not up to par. Were the various attempts at rewrites (Jade, etc.) driven in any way to get the source cleaned up?
Is there any "guest" who knows enough to fill in the blanks and give us some warm fuzzies for the future?
This is the first I have heard of the assembler conversion not being well documented. It does make sense why they have been loathe to make what we feel are necessary changes to PRO-IV. They had to have made that conversion back in the 80's when they first came out with version 1.5. So hopefully much of the work since then is clean and documented. How big an albatross is that old converted code? I'm sure no one will freely admit. I have to say, it does make me nervous knowing the source is not up to par. Were the various attempts at rewrites (Jade, etc.) driven in any way to get the source cleaned up?
Is there any "guest" who knows enough to fill in the blanks and give us some warm fuzzies for the future?
Reply to this topic
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users
Click the link below to see the new game I'm developing!
