SYSTEM(14) with D3

#1

Is there a way to use the DATA statement, or something similar, to pass
data to a new program and have SYSTEM(14) reflect the number of bytes
to be used for input in the program started by the EXECUTE statement?

I have tried DATA and STACKING with the same results.

DATA1
001 TEXT = "This is the input stream."
002 DATA TEXT
003 EXECUTE "RUN BP DATA2"
004 STOP
005 END

DATA2
001 CRT "SYSTEM(10) = ":SYSTEM(10) ; * TRUE if stacked data active;
FALSE if not
002 CRT "SYSTEM(14) = ":SYSTEM(14) ; * the number of bytes in the
type-ahead input buffer
003 INPUT WAIT
004 CRT WAIT
005 STOP
006 END

RUN BP DATA1
SYSTEM(10) = 1
SYSTEM(14) = 0
This is the input stream.

#2

Off the top of my head, it seems to me that DATA queues are different
than the type-ahead buffer. If I am correct in that assumption then
SYSTEM(14) is not what you would want to use.

Could you delimit the text string and append the results of the
LEN(TEXT) function, i.e.

DATA TEXT:@VM:LEN(TEXT); * or use whatever character you wish as a
delimiter

and then process that after your INPUT statement?

Or, just perform the LEN() function after the INPUT in the second
program...I'm not sure if you need to know the length of the string
before and after entering the second program (sort of a CRC check
scenario) or can determine it after.

-Bruce H

cmeister (AT) tpsrx (DOT) com wrote:

Quote:

Is there a way to use the DATA statement, or something similar, to pass
data to a new program and have SYSTEM(14) reflect the number of bytes
to be used for input in the program started by the EXECUTE statement?

I have tried DATA and STACKING with the same results.

DATA1
001 TEXT = "This is the input stream."
002 DATA TEXT
003 EXECUTE "RUN BP DATA2"
004 STOP
005 END

DATA2
001 CRT "SYSTEM(10) = ":SYSTEM(10) ; * TRUE if stacked data active;
FALSE if not
002 CRT "SYSTEM(14) = ":SYSTEM(14) ; * the number of bytes in the
type-ahead input buffer
003 INPUT WAIT
004 CRT WAIT
005 STOP
006 END

RUN BP DATA1
SYSTEM(10) = 1
SYSTEM(14) = 0
This is the input stream.

#3

I am trying to duplicate the type of input that comes into a program in
the type ahead buffer. I thought the DATA statement would be a good
place to start.

mvdbman wrote:

Quote:

Off the top of my head, it seems to me that DATA queues are different
than the type-ahead buffer. If I am correct in that assumption then
SYSTEM(14) is not what you would want to use.

Could you delimit the text string and append the results of the
LEN(TEXT) function, i.e.

DATA TEXT:@VM:LEN(TEXT); * or use whatever character you wish as a
delimiter

and then process that after your INPUT statement?

Or, just perform the LEN() function after the INPUT in the second
program...I'm not sure if you need to know the length of the string
before and after entering the second program (sort of a CRC check
scenario) or can determine it after.

-Bruce H

cmeister (AT) tpsrx (DOT) com wrote:
Is there a way to use the DATA statement, or something similar, to pass
data to a new program and have SYSTEM(14) reflect the number of bytes
to be used for input in the program started by the EXECUTE statement?

I have tried DATA and STACKING with the same results.

DATA1
001 TEXT = "This is the input stream."
002 DATA TEXT
003 EXECUTE "RUN BP DATA2"
004 STOP
005 END

DATA2
001 CRT "SYSTEM(10) = ":SYSTEM(10) ; * TRUE if stacked data active;
FALSE if not
002 CRT "SYSTEM(14) = ":SYSTEM(14) ; * the number of bytes in the
type-ahead input buffer
003 INPUT WAIT
004 CRT WAIT
005 STOP
006 END

RUN BP DATA1
SYSTEM(10) = 1
SYSTEM(14) = 0
This is the input stream.

#4

Quote:

cmeister (AT) tpsrx (DOT) com wrote:
Is there a way to use the DATA statement, or something similar, to pass
data to a new program and have SYSTEM(14) reflect the number of bytes
to be used for input in the program started by the EXECUTE statement?

"mvdbman" wrote

Quote:

Off the top of my head, it seems to me that DATA queues are different
than the type-ahead buffer. If I am correct in that assumption then
SYSTEM(14) is not what you would want to use.

Could you delimit the text string and append the results of the
LEN(TEXT) function, i.e.

DATA TEXT:@VM:LEN(TEXT); * or use whatever character you wish as a
delimiter

and then process that after your INPUT statement?

-Bruce H

You could also pass data in named COMMON, which doesn't go away until
you freakin' LOG OFF of that port. Talk about overly-durable data!
Note: if you want to access a variable, but suspect it hasn't ever been written to yet,
do IF ASSIGNED(myvariable) THEN .... ELSE ....
is also a neat trick when you're not sure if a certain file handle has been opened yet.

#5

Frank Winans wrote:

Quote:

You could also pass data in named COMMON, which doesn't go away until
you freakin' LOG OFF of that port. Talk about overly-durable data!

It gets worse. Named COMMON survives a LOGTO as well. Which can be
murder if you use it to open files and don't have some mechanism in your
login PROC to reset it.

Quote:

Note: if you want to access a variable, but suspect it hasn't ever been written to yet,
do IF ASSIGNED(myvariable) THEN .... ELSE ....
is also a neat trick when you're not sure if a certain file handle has been opened yet.

I use that to limit the number of file OPENs that take place. But watch
that LOGTO, folks.

Luke

#6

Luke Webber wrote:

Quote:

Frank Winans wrote:

You could also pass data in named COMMON, which doesn't go away until
you freakin' LOG OFF of that port. Talk about overly-durable data!

That's by design.

Quote:

It gets worse. Named COMMON survives a LOGTO as well. Which can be
murder if you use it to open files and don't have some mechanism in your
login PROC to reset it.

ooops... that's a serious bug! ouch!

a workaround would be to have a uniquely named common associated with
an account, eg. 'common /sysprog_myCommon/ a,b,c '

#7

dzigray wrote:

Quote:

Luke Webber wrote:

It gets worse. Named COMMON survives a LOGTO as well. Which can be
murder if you use it to open files and don't have some mechanism in your
login PROC to reset it.

ooops... that's a serious bug! ouch!

a workaround would be to have a uniquely named common associated with
an account, eg. 'common /sysprog_myCommon/ a,b,c '

A feature I'd say - if you have account specific stuff youyr LOGON proc
needs to store the result of a WHO in one of the labelled common
variables, providing a way to reset if required.

Could also then have a 2 dimensional array, with one dimension per
account you had to visit to reduce file opens eg:

common /mystuff/ ms.account, ms.index, ms.info(1000,10)

if you were visiting <= 10 accounts

REALLY, the process used to populate common in the logon process should
do so UNCONDITIONALLY, rather than checking to see if things are set.

#8

Ross Ferris wrote:

Quote:

A feature I'd say - if you have account specific stuff youyr LOGON proc
needs to store the result of a WHO in one of the labelled common
variables, providing a way to reset if required.
There's numerous problems here... your common maps may not be

consistent between the two accounts. even if they are consistent, the
various conventions used to initialize common elements (eg. if
assign()) -- could easily fail or cause obscure results based upon
downstream logic.

Quote:

Could also then have a 2 dimensional array, with one dimension per
account you had to visit to reduce file opens eg:

common /mystuff/ ms.account, ms.index, ms.info(1000,10)

if you were visiting <= 10 accounts
sure... as a more sophisticated workaround. (this might create harder

to maintain named common elements, however, or require an index map to
make up for it...)

Quote:

REALLY, the process used to populate common in the logon process should
do so UNCONDITIONALLY, rather than checking to see if things are set.
that's probably a good practice, but limited to scenarios where the

initialization logic is promotable to logon time... where often such is
never referenced until first required. along this line, one could
always create a fake 'uninitialized variable' that is set to true at
login and then this variable is tested for such a scenario...

but all this is substantial workarounds for a bug that has ultra-remote
side-effect advantages and can really blind-side many-a-developer.

named common is also used often in aql reports and i can see scenarios
where all initialization logic would go to heck (including first-time
file-references), especially when the same file name exists between two
accounts.

#9

Ross Ferris wrote:

Quote:

dzigray wrote:
Luke Webber wrote:

It gets worse. Named COMMON survives a LOGTO as well. Which can be
murder if you use it to open files and don't have some mechanism in your
login PROC to reset it.

ooops... that's a serious bug! ouch!

a workaround would be to have a uniquely named common associated with
an account, eg. 'common /sysprog_myCommon/ a,b,c '

Blergh. No thanks. That's as bad as the whole "full path" shitfight. <g>

Quote:

A feature I'd say - if you have account specific stuff youyr LOGON proc
needs to store the result of a WHO in one of the labelled common
variables, providing a way to reset if required.

The whole bug or feature question really rests on one question. What do
the other implementations do in this situation? Since named common was
modelled on the Pr1me and U2 versions, I would want it to behave pretty
much exactly the same way.

Quote:

Could also then have a 2 dimensional array, with one dimension per
account you had to visit to reduce file opens eg:

common /mystuff/ ms.account, ms.index, ms.info(1000,10)

if you were visiting <= 10 accounts

Kill me now, please! ;^)

Quote:

REALLY, the process used to populate common in the logon process should
do so UNCONDITIONALLY, rather than checking to see if things are set.

Or you could just reset the flag that tells the subroutine that
initialisation has been done.

Cheers,
Luke

#10

dzigray wrote:
[snip]

Quote:

There's numerous problems here... your common maps may not be
consistent between the two accounts. even if they are consistent, the
various conventions used to initialize common elements (eg. if
assign()) -- could easily fail or cause obscure results based upon
downstream logic.
[snip]
but all this is substantial workarounds for a bug that has ultra-remote
side-effect advantages and can really blind-side many-a-developer.

named common is also used often in aql reports and i can see scenarios
where all initialization logic would go to heck (including first-time
file-references), especially when the same file name exists between two
accounts.

Precisely. The first time I was very nearly bitten by it was in logging
between live and test accounts. Picture me blithely sitting at my
keyboard running test code over live data. Could have been nasty!

Luke