[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Nothing.
When you execute an accept statement it will "listen" for messages from Windows, some of those messages will be characters, those will be collected.
ACCEPT doesn't really belong in the structure of how the Windows operating system works, technically speaking.
Obviously, in COBOL we have to use it.
How come you ask?
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Nothing.
When you execute an accept statement it will "listen" for messages from Windows, some of those messages will be characters, those will be collected.
ACCEPT doesn't really belong in the structure of how the Windows operating system works, technically speaking.
Obviously, in COBOL we have to use it.
How come you ask?
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Gisle, I think you may have missed the point of the question - accept from line number doesn't accept any input, it returns a value.
"accept from line number" has its roots in DG ICOBOL. On DG and later on Unix, it returns the digits at the end of the current tty device (i.e. if you are running on /dev/tty15, "accept from line number" will return 15). You can override it by setting an environment variable with the same name as the device.
On Windows, there is no similar unique device name associated with the session - the "device" is always "CON", which is the Windows console device name.
What I have found is "accept from line number" will always return zero under Windows, unless you set the environment variable "CON", either in the Windows environment or in the Acucobol configuration file.
For example, if you set the environment variable "CON" to 50, then "accept line number" will return 50.
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
A followup... for a bit of history from us "old timers", at one time the line number was useful information, when everyone connected to the DG system and later Unix system via serial terminals. For the most part, everyone got a unique number (/dev/tty1, /dev/tty2, etc.).
Once people started using telnet clients, it became less useful because (1) you could have multiple telnet sessions from the same workstation, each getting a different line number, (2) you could have conflicts with the serial devices (/dev/tty5 and /dev/pts/5 or /dev/pty5 all returned 5), and (3) the number changed as users logged in and out - that is, you used to be able to store information based on the line number and tie it back to a specific terminal, but with telnet sessions, you potentially get a different line number each time you log in because the psuedo-tty device could be different depending on how many other sessions are active.
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Thanks JoeD, that answers my question ... we are indeed migrating a bunch of character based icobol programs to acu. We use the console number (automatically uniquely assigned in icobol) to track a single run unit, name temp files, etc.
I'm assuming there is a superior modern way of doing this?
Thanks!
Steve
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Thanks JoeD, that answers my question ... we are indeed migrating a bunch of character based icobol programs to acu. We use the console number (automatically uniquely assigned in icobol) to track a single run unit, name temp files, etc.
I'm assuming there is a superior modern way of doing this?
Thanks!
Steve
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
If you are porting the programs to Windows, one way to do it is to assign the file to a name with "%TMP%" and the runtime will substitute a unique name for the "%TMP%".
We took a little different approach - upon startup of our menu system, we open an indexed file and try to read & lock sequentially numbered records in it. Once it finds a record that is not locked (or does not exist), it locks it and holds that record locked for the duration of that user's session, and the record number is used as their "line number".
When the runtime exits (or if it aborts), the lock automatically gets released by the operating system.
We actually use this method to count users against a license, but as a byproduct you get a unique number for each user's session.
The pseudo-code for this method is:
open i-o lock-file
move 1 to lock-key.
while found = "N" or err = "Y"
read lock-file with lock
evaluate status
when locked
add 1 to lock-key
if lock-key > licensed-users
report license exceeded
move "Y" to err
end-if
when not-found
write lock-record
read lock-file with lock
move "Y" to found
when OK
move "Y" to found
when other-error
blow up
end-evaluate
end while
The value in lock-key is now unique to that user's session.
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
Actually, that should be:
while found = "N" and err = "N"
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
JoeD, thanks so much for the information on this, quite interesting!
I must admit that I did not understand the question in the first place, but nor did I know what you said.
[Migrated content. Thread originally posted on 22 March 2005]
Can anyone tell me what is used for the "device" string on windows?
Thanks,
Steve
JoeD, thanks so much for the information on this, quite interesting!
I must admit that I did not understand the question in the first place, but nor did I know what you said.