Julius is an Avid Commentator
76 published comments for 2024
User bio
404 bio not found
Member since Jul 25, 2017
Replies:

Some comments (and please excuse the rude comments) before my answer
1) in general, it's never a good idea, to enforce a "new coding standard" for an old code. This is especially valid for old MUMPS and old ObjectScript code - except, you redesign or at least rework, the entire codebase.
2) use the Codesnippet button to write a more readable code (it's not necessary, but it helps us)
3) include only relevant parts/lines of code, in the above code, all that ^OLIVERs are completely irrelevant and makes the reading and understanding of an foreigen code more difficult, with other words, help us to help you!

And now to your problem. The old code is written in a mode, which we call "non procedural" code, i.e. all variables are public except the NEWed (which are invisible). The original code changes or kills at least the OLDIO543 variable, somewhere in the called part (do @CALL), and this fact is considered with the

 N TMPFILE,OLDIO
 S OLDIO=$IO
 I $G(^TMP("RMPV","SILENT"),1) S IOP="NULL",%ZIS=0 D ^%ZIS I '$G(POP,1) U IO
 D INIT^@DRVNAME
 D  ; scope variables
 .N (DUZ,CALL) ; Protect %response  // <-- save all except DUZ and call
 .S IOF="""""",IOM=80,U="^"
 .D @CALL
 U OLDIO

To move all commands from argumentless DO into a classmethod is OK, but you can't change a "non procedural" flow to a "procedural"!
So the solution is, you leave the old NEW as is and define your class method as:

ClassMethod doCall() [ ProcedureBlock=0 ]
{
 ...
}

If you want to keep your procedural code then you have to rework the code, which is called by "do @CALL" too and probably the code which is called from inside of "DO @CALL". Good luck!

This is the rare case where the statement “RTFM” leads you down the wrong path or, better said, reading the documentation confuses you more than informs.

So you have to change your viewpoint. And that depends on, what do you do.
If you work with ObjectScript (and of course, with objects) then your first citation "Case-sensitive: variable names..." holds.

But if you are more that SQL guy, who day in, day out busy with Updates, Inserts and Selects, then you will say, "No, no, my table and field names aren't case sensitive".

And now we sit in the middle of those two worlds, where a case sensitive Objectscript meets a case insensitive SQL world.

So what is the status quo?

All the (persistent) classes can be seen (and used) as SQL tables, but this freedom has its price (or, better, its consequence): you must be aware, that the two worlds (ObjectScript and SQL) do not use the same case-rule.

An ObjecScript class Test.Person can be named in SQL as Test.Person, as TEST.Person, as TEST.PERSON or even as TeSt.PeRsOn.

To de-escalate the resulting confusion, the following rule was added:

It's forbidden to have two ObjectScript classes, which have the same spelling but (somewhere) a different case (the Studio wizard checks this). I hope, this helps a bit...

Certifications & Credly badges:
Julius has no Certifications & Credly badges yet.
Global Masters badges:
Followers:
Following:
Julius has not followed anybody yet.