Customize command to optionally accept strings for DOWNLOAD and UPLOAD

[jjacobs207]

Customize command to optionally accept strings for DOWNLOAD and UPLOAD

I see that http_string for shorter strings and http_req for longer strings can be used as an alternative to IFS files.

Is there anything special needed regarding CCSIDs with the strings being used on those function calls or does it depend on target? If so, can anyone specify what would need to be done (http_setOption calls, etc.)?

Thanks!

[Scott Klement]

Customize command to optionally accept strings for DOWNLOAD and UPLOAD

I'm not sure what this means. What are you referring to?

I see that http_string for shorter strings and http_req for longer strings can be used as an alternative to IFS files.

Yes.

Though, you could make the argument that the IFS files are an alternative to longer strings... But yeah, you can do it either way, either from files or strings...

Is there anything special needed regarding CCSIDs with the strings being used on those function calls or does it depend on target? If so, can anyone specify what would need to be done (http_setOption calls, etc.)?

Not sure what you are asking, here. "Is there anything special" is always a loaded question... what do you consider to be special?

You should set the local CCSID to the CCSID of the data you're sending, and the network CCSID to whatever the other end of the connection is expecting (typically, that would be UTF-8... but there are still exceptions.)

I don't consider that to be "special"... that's just what makes sense when sending stuff over a network.

[jjacobs207]

Thanks, Scott!

There are often times when the data being posted (Request Data) and received back (Response Data) is not that large, so using IFS files work, but it's more work to do and more STMF objects to manage (write/read/unlink/archive/etc.). I would like to modify the HTTPAPI command and CPP to allow either an IFS file or a character variable for DOWNLOAD and UPLOAD parms.

I would add an additional parm for the DOWNLOAD character string and another for the UPLOAD character string. Then, either: on the character string parms, use special value *STMF to indicate that an IFS file is being used or on the IFS file parm, use *STRING to indicate that a character string is being used.

In any case, I haven't done it before, but I understand your comment about using http_setOption for network CCSID. Regarding the data I'm sending in a regular RPG ILE character variable, do I need to set the local CCSID to something in particular or simply not mess with it? I'm not an expert on working with CCSIDs and am wondering if CCSID data definition keywords are necessary for the Request and Response character string variables, potentially in addition to setting the CCSID using the http_setOption function.

[Scott Klement]

There are often times when the data being posted (Request Data) and received back (Response Data) is not that large, so using IFS files work, but it's more work to do and more STMF objects to manage (write/read/unlink/archive/etc.). I would like to modify the HTTPAPI command and CPP to allow either an IFS file or a character variable for DOWNLOAD and UPLOAD parms.

I would add an additional parm for the DOWNLOAD character string and another for the UPLOAD character string. Then, either: on the character string parms, use special value *STMF to indicate that an IFS file is being used or on the IFS file parm, use *STRING to indicate that a character string is being used.

Ah, okay, you're talking about the *CMD interface. (Discussions about that don't come up often.) Sure, that could be added, I guess.. the only caveat that I can think of is that if you add a parameter for returning data to a CL variable, you'll be forced to write this command such that it can only be called from a CL program. That is a big problem because a number of people call this command directly from the command-line without using a program.

So if this is needed, we'd have to add a separate command for it. Or, perhaps it'd make more sense for CL programmers to simply call the ILE routines directly, like you would from RPG?

In any case, I haven't done it before, but I understand your comment about using http_setOption for network CCSID. Regarding the data I'm sending in a regular RPG ILE character variable, do I need to set the local CCSID to something in particular or simply not mess with it? I'm not an expert on working with CCSIDs and am wondering if CCSID data definition keywords are necessary for the Request and Response character string variables, potentially in addition to setting the CCSID using the http_setOption function.

By default the local data CCSID is the job's CCSID -- which is to say, it is the flavor of EBCDIC that is set via the system values (QCCSID, QLANG, etc. And the job-level versions of the same...) This is normally what people use in their RPG CHAR/VARCHAR variables, that's why this is the default. You don't want to code the CCSID keyword on your variable definitions because RPG will convert data when assigning between varaibles that have different CCSID keywords -- and since the prototypes for HTTPAPI don't have CCSID keywords on them, that means your data would be translated between CCSIDs before it is even given to HTTPAPI, which in turn would try to translate them again... Unless, of course, you're using pointers to pass it to HTTPAPI.

The CCSID keyword and *UTF8 support for RPG CHAR/VARCHAR fields was added in V7R2, and HTTPAPI currently still supports V7R1, so I can't incorporate support for the RPG CCSID support on the HTTPAPI prototypes yet.

So generally, no... you don't want to use the CCSID keywords. If you load data that's not in the job CCSID into an RPG variable (without changing the CCSID keyword) then you should change the local CCSID with HTTP_setOption to match the format of the data you've provided.

[jjacobs207]

Scott, thank you for your quick response.

I did not want to touch your HTTPAPI command or CPP and risk breaking them. Thank you for providing this excellent tool by the way. I'm using it for the first time at the company I work for to do REST API calls with/without OAUTH2 from iSeries.

A separate command is not an issue in my opinion. I already created HTTPAPIB and a new CPP to accept up to 10 user-defined header key-value pairs. I also create a CLLE utility program that accepts all the parms and executes HTTPAPIB from there.

We are on V7R2 and our system has QCCSID set to 65535, and our jobs do not currently override this, so the job will by default have a CCSID of 65535. Given this, does that change what you stated about not using CCSIDs on the RPG variables? Also, I'll be building/generating the XML/JSON data in my program, storing into a VARCHAR variable, so I'm not sure what that means in terms of your comment "If you load data that's not in the job CCSID into an RPG variable". I can certainly experiment with my enhancement idea. I'm hoping, given the information I've provided, that at least on the Request Data side of things, you'd have a good idea of what my proposal would look like regarding CCSIDs in the RPG and local setting of CCSID via http_setOption. Thanks for your help!

[Scott Klement]

We are on V7R2 and our system has QCCSID set to 65535, and our jobs do not currently override this, so the job will by default have a CCSID of 65535. Given this, does that change what you stated about not using CCSIDs on the RPG variables?

That does not speak highly of the person who makes decisions about your system configuration.

But, no... it has no impact on what I said about the RPG variables. If the CCSID is 65535, it will use the "default CCSID" which is derived from the country/language settings.

Use DSPJOB, take option 2, and page down to "Coded character set identifier" (which is what CCSID stands for) yours should be 65535. Right beneath that, you'll find the "Default coded character set identifier". That's what HTTPAPI will treat your variables as.

Also, I'll be building/generating the XML/JSON data in my program, storing into a VARCHAR variable, so I'm not sure what that means in terms of your comment "If you load data that's not in the job CCSID into an RPG variable".

Will the letters, numbers and other symbols in your XML/JSON data be in the job CCSID (EBCDIC) or something else? Knowing that it's XML or JSON doesn't help...

[jjacobs207]

Okay, the default CCSID on my job is 37, and I'm not overriding the CCSID on my variables, so the data in my variables will be EBCDIC.

[Scott Klement]

Actually "37" was far more specific than "EBCDIC". EBCDIC is a whole classifcation of character sets (there are many different EBCDICs... 37 is a specific one.)

[jjacobs207]

Scott, I wanted to let you know where I got with modifying the CMD/CPP to fit what I think is most useful for the project I'm working on.

I created a new command HTTPAPIC with CPP HTTPCMDR4C, so I could leave your original command as is. HTTPAPIC must be run from an interactive or batch program/module because it has Return Values.

Command enhancements:

• Up to 10 User-defined Header key/value pairs (Key 32A, Value 3072A)
  A value of *STRING is allowed on the DOWNLOAD and UPLOAD keywords
  CL variable to hold the optional Download response data when not using an IFS file (String 32767A)
  CL variable to hold the optional Upload request data when not using an IFS file (String 32767A)
  CL variable to hold the optional HTTP Response Status Code (Decimal 3,0)

I considered adding CCSID keywords for the input and output IFS files, since the YAJL_saveBuf procedure always created the IFS file with CCSID 1208, and I needed CCSID 819. However, I used YAJL_copyBuf and a WriteToIFS utility program that allows a CCSID to be passed to get around the issue.

My latest need is to use your JDBCR4 solution to retrieve data to the iSeries from a remote SQL Server database. I'm having an issue from the get-go with the start_jvm procedure that's kicked off by my RPGLE code executing JDBC_Properties procedure. The error is "Unable to create Java Virtual Machine". I added a post for my issue in the JDBCR4 forum. I would appreciate your assistance here once again. Thanks!