I wonder?
No matter how carefully you decide you'll allocate actual line
numbers in PB 3.5 for program use in error handling mostly, there
comes a time...
A time with 25,000 lines per program including CALLS, libraries,
Units, whatever - that it is necessary to make statements between
contiguous physical numeric line labels in the code. At least that
has happened here.
OK. So what? Well, you can use the ":" mark to delimit statements
in the source code with many of them on one line.
OK .. you can also, in the quest to make code more understandable
and easier to maintain, simply move to what I've done totally and
go to one line per statement.
But .. I'm curious. Is there a maximum number of physical statements
either coded with ":" separators on one line, or into single none
labeled pure one statement per line uses you can make between two
physical adjacent number sequence numeric line labels in PB 3.5.
**********************************
Reason I'm curious is that once again I just spent another seven hours
here chasing the mysterious SYS3170 error in very large executables in
OS/2 DOS-VDM's in huge PB executables. This error is:
[C:\]help sys3170
SYS3170: A program in this session encountered a problem and
cannot continue.
EXPLANATION: The process was ended because the program generated
an unhandled fatal user (non-system) exception through DosRaiseException.
ACTION: If you purchased this program, contact the supplier of the
program. If you are the developer of this program, refer to the
information in the register.
************************************
There is no way to debug these large programs here with PBD as there
simply isn't enough memory to even operate them, even with 675K of
free memory at the raw command prompt line. Thus I wind up hand
inserting little break point traps line after line one at a time
until I can find the exact place where the trap takes place.
Here, once again, hours later I'm faced with the 'solution' which is
a simple numeric line lable in the source of 37899 in the below. If
I don't add a line lable to it we get the SYS3170 .. or SYS3176
is possible too. With the following, absolute stable runtime:
Now I already know from long BITTER experience I can't put any actual
operational code directly adjacent to a non-numeric line lable as
is shown above. But that's another story..
Remove that 37899 numeric line lable and the whole DOS-VDM session
comes crashing down. It's the first time in all these years it has
popped to my attention that could this be related to the total number
of statements between two adjacent numeric line lables? There is a
lable above it statements back of 37899 and, in this case, a numeric
line lable for error trap reporting purposes of 37902.
Thoughts?
------------------
Mike Luther
[email protected]
No matter how carefully you decide you'll allocate actual line
numbers in PB 3.5 for program use in error handling mostly, there
comes a time...
A time with 25,000 lines per program including CALLS, libraries,
Units, whatever - that it is necessary to make statements between
contiguous physical numeric line labels in the code. At least that
has happened here.
OK. So what? Well, you can use the ":" mark to delimit statements
in the source code with many of them on one line.
OK .. you can also, in the quest to make code more understandable
and easier to maintain, simply move to what I've done totally and
go to one line per statement.
But .. I'm curious. Is there a maximum number of physical statements
either coded with ":" separators on one line, or into single none
labeled pure one statement per line uses you can make between two
physical adjacent number sequence numeric line labels in PB 3.5.
**********************************
Reason I'm curious is that once again I just spent another seven hours
here chasing the mysterious SYS3170 error in very large executables in
OS/2 DOS-VDM's in huge PB executables. This error is:
[C:\]help sys3170
SYS3170: A program in this session encountered a problem and
cannot continue.
EXPLANATION: The process was ended because the program generated
an unhandled fatal user (non-system) exception through DosRaiseException.
ACTION: If you purchased this program, contact the supplier of the
program. If you are the developer of this program, refer to the
information in the register.
************************************
There is no way to debug these large programs here with PBD as there
simply isn't enough memory to even operate them, even with 675K of
free memory at the raw command prompt line. Thus I wind up hand
inserting little break point traps line after line one at a time
until I can find the exact place where the trap takes place.
Here, once again, hours later I'm faced with the 'solution' which is
a simple numeric line lable in the source of 37899 in the below. If
I don't add a line lable to it we get the SYS3170 .. or SYS3176
is possible too. With the following, absolute stable runtime:
Code:
SUB AP37894 (DTMEORG$, Y2$, GFF%, HT%, L%, LL%) PUBLIC ' CVRTTIME: 37899 Y2$ = DTMEORG$ ' Set to convert selected time IF VAL(Y2$) < 0 OR VAL(Y2$) > 2359 THEN GOTO APDCV1 ' Units per hour END IF IF LEN(Y2$) < 3 OR LEN(Y2$) > 6 OR INSTR(Y2$, ":") > 0 THEN GOTO APDCV1 ' Is bad END IF IF LEN(Y2$) > 4 THEN GOTO APDCV1 ' Is bad END IF IF VAL(Y2$) < 1159 THEN ' Fix it up Y2$ = Y2$ + "AM" ELSE Y2$ = Y2$ + "PM" END IF IF RIGHT$(Y2$, 1) = "M" OR RIGHT$(Y2$, 1) = "m" THEN GOTO APDCV2 END IF APDCV1: GFF% = 1 ' Set bad time flag EXIT SUB APDCV2: etc..
operational code directly adjacent to a non-numeric line lable as
is shown above. But that's another story..
Remove that 37899 numeric line lable and the whole DOS-VDM session
comes crashing down. It's the first time in all these years it has
popped to my attention that could this be related to the total number
of statements between two adjacent numeric line lables? There is a
lable above it statements back of 37899 and, in this case, a numeric
line lable for error trap reporting purposes of 37902.
Thoughts?
------------------
Mike Luther
[email protected]
Comment