Recent Posts
21
Programming / Re: Strange if then else behavior
« Last post by Mike King on March 08, 2023, 11:08:52 PM »Add a comma after the label to start the list from there. Without a trailing comma you will only get one line.
22
Programming / Re: Strange if then else behavior
« Last post by Mike Hatfield on March 08, 2023, 06:15:22 PM »Hi Mike, I had no idea you could do a LIST EDIT..... from the console prompt. very handy I think.
So, I thought I'd try it on the inomads program. The IT editor is set to 'editted list' and 'disallow lines'
I get this
-}LIST EDIT SET_USERID
0071 Set_userid:
:
Am I missing a setting somewhere?
Thanks
So, I thought I'd try it on the inomads program. The IT editor is set to 'editted list' and 'disallow lines'
I get this
-}LIST EDIT SET_USERID
0071 Set_userid:
:
Am I missing a setting somewhere?
Thanks
23
Programming / Re: Strange if then else behavior
« Last post by Mike King on March 08, 2023, 05:28:41 PM »Quick follow up:
To give you an idea of how my coding style looks have a look at *plus/inomads/inomads around the label Set_Userid:
If you load this program and do a standard LIST EDIT SET_USERID (or call the program up in the *it or *ed+ editors with Formatted output enabled) you will get something like this:
Set_userid:
IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y" \
THEN %inomads'Userid$=NID;
RETURN
!
DEF UID="*Void*" LOCAL
CALL "*secure","F:LOGIN"
DEF UID="*"
!
IF %inomads'Userid$="" \
THEN objsec=NEW("*secure");
IF objsec'unsecured \
THEN MSGBOX "System security is not enabled but required for this transaction","Error","STOP";
EXITTO SKIP_TX \
ELSE EXITTO SKIP_TX
!
IF %inomads'use_signon_uid \
THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid$
!
RETURN
Which I find fairly easy to read and follow.
Now some of the lines if you list them un-formatted are quite long, with edited listing enabled the built in code formatting makes following the logic quite easy -- and in my opinion much easier than coding a bunch of brackets.
To give you an idea of how my coding style looks have a look at *plus/inomads/inomads around the label Set_Userid:
If you load this program and do a standard LIST EDIT SET_USERID (or call the program up in the *it or *ed+ editors with Formatted output enabled) you will get something like this:
Set_userid:
IF NOT(%inomads'ForceLogon) AND %inomads'LogonReqd$<>"Y" \
THEN %inomads'Userid$=NID;
RETURN
!
DEF UID="*Void*" LOCAL
CALL "*secure","F:LOGIN"
DEF UID="*"
!
IF %inomads'Userid$="" \
THEN objsec=NEW("*secure");
IF objsec'unsecured \
THEN MSGBOX "System security is not enabled but required for this transaction","Error","STOP";
EXITTO SKIP_TX \
ELSE EXITTO SKIP_TX
!
IF %inomads'use_signon_uid \
THEN GOSUB Linux_signon WITH reqd_uid$=%inomads'Userid$
!
RETURN
Which I find fairly easy to read and follow.
Now some of the lines if you list them un-formatted are quite long, with edited listing enabled the built in code formatting makes following the logic quite easy -- and in my opinion much easier than coding a bunch of brackets.
24
Programming / Re: Strange if then else behavior
« Last post by Mike King on March 08, 2023, 05:13:16 PM »The issue is a result of the line oriented nature of the language. IF ... THEN ... ELSE ... will basically process what is on the line.
To span multiple lines then the THEN or the ELSE *MUST* be immediately followed by the OPEN bracket otherwise the conditional processing ends.
What was happening is that when the system saw your ELSE IF MIKE$=... because the ELSE was not followed by a curly bracket the IF directive was now fully complete thus the next line was executed.
Personally I try to avoid curly brackets as they make lines hard to read. I would enable formatted output in *IT and code the line as:
0005 mike$="P"
0010 IF mike$="P" \
THEN PRINT "Yes P" \
ELSE IF mike$="T" \
THEN PRINT "Doing T too"
0020 !
Its just easier to read.
And where there are more than three lines in any of the of the IF blocks I usually put the code into a GOSUB with a label to make the code more readable. For example in instead of just PRINT "Yes P" you had 10 lines of code to execute I'd put that in a GOSUB called something like Mike_Code_P. (My $0.02)
To span multiple lines then the THEN or the ELSE *MUST* be immediately followed by the OPEN bracket otherwise the conditional processing ends.
What was happening is that when the system saw your ELSE IF MIKE$=... because the ELSE was not followed by a curly bracket the IF directive was now fully complete thus the next line was executed.
Personally I try to avoid curly brackets as they make lines hard to read. I would enable formatted output in *IT and code the line as:
0005 mike$="P"
0010 IF mike$="P" \
THEN PRINT "Yes P" \
ELSE IF mike$="T" \
THEN PRINT "Doing T too"
0020 !
Its just easier to read.
And where there are more than three lines in any of the of the IF blocks I usually put the code into a GOSUB with a label to make the code more readable. For example in instead of just PRINT "Yes P" you had 10 lines of code to execute I'd put that in a GOSUB called something like Mike_Code_P. (My $0.02)
25
Programming / Re: Strange if then else behavior
« Last post by James Zukowski on March 08, 2023, 09:36:37 AM »Yes, it looks like it should. If you add a brace before the second IF and close it at 35, it works fine. Evidently, if you {group statements} for the THEN, it's expected for the ELSE as well.
26
Programming / Strange if then else behavior
« Last post by michaelgreer on March 08, 2023, 09:00:05 AM »This is an abstraction of a code issue we are seeing:
0005 let mike$="P"
0010 if mike$="P" then {
0015 print "Yes P"
0020 } else if mike$="T" then {
0025 print "Doing T too"
0030 }
If you execute this, you get both outputs when it seems you should not get the "Doing T too". I realize this is not great coding (I didn't write it) but it seems it should work.
0005 let mike$="P"
0010 if mike$="P" then {
0015 print "Yes P"
0020 } else if mike$="T" then {
0025 print "Doing T too"
0030 }
If you execute this, you get both outputs when it seems you should not get the "Doing T too". I realize this is not great coding (I didn't write it) but it seems it should work.
27
Language / Re: *X Mnemonic / Print Channel Timing Question
« Last post by Jeffrey Ferreira on March 07, 2023, 04:32:30 PM »Thank you Allen and Mike. I appreciate it.
28
Language / Re: *X Mnemonic / Print Channel Timing Question
« Last post by Mike King on March 07, 2023, 04:18:52 PM »Jeff
No, you can safely close the file in your *X logic. The system checks for this and handles it appropriately.
No, you can safely close the file in your *X logic. The system checks for this and handles it appropriately.
29
Language / Re: *X Mnemonic / Print Channel Timing Question
« Last post by Jeffrey Ferreira on March 07, 2023, 11:19:05 AM »Hi Allen,
thank you.
so closing the file (again) is not forbidden or bad.
jeff
thank you.
so closing the file (again) is not forbidden or bad.
jeff
30
Language / Re: *X Mnemonic / Print Channel Timing Question
« Last post by Allen Miglore on March 07, 2023, 10:32:59 AM »This aligns with the documentation. I found that the behavior changed way back at pvx 6.
'*X' (asterisk X) contains the pathname of a program to CALL on the closing of a channel. When a file is closed, PxPlus issues a CALL to the program/entry point specified by the contents of '*X'. This takes place just prior the file being actually being closed, allowing the program to alter the contents of the file if desired.
'*X' (asterisk X) contains the pathname of a program to CALL on the closing of a channel. When a file is closed, PxPlus issues a CALL to the program/entry point specified by the contents of '*X'. This takes place just prior the file being actually being closed, allowing the program to alter the contents of the file if desired.