any way i can find whether a file is migrated state within JCL ?
i need to put condition in my jcl depending on the location of the file, like how we can refer the creation, reference, expiration date..
JCL does not have the ability to query attributes; it is merely a method of referencing where data is, or specifying criteria for creating data.
If you need this type of information, it sounds like you need a REXX procedure. REXX is the primary scripting language for IBM mainframe operating systems. (There are implementations for the LUW world.) In REXX, you have access to several items which can help you:
IGGCSI00, the Catalog Interface - this is an interface to most of the data returned by the IDCAMS LISTCAT command.
The SYSDSN() function, which is a quick way of determining whether or not a data set exists (along with a few extra status values)
The LISTDSI() function, which once you validate with SYSDSN(), retrieves many different pieces of information about a data set. Most of what you are looking for is there.
IGGCSI00 is documented in the DFSMS Managing Catalogs book, in the chapter called "Catalog Search Interface User's Guide". The other two are documented in the "TSO/E REXX Reference."
Related
I'm working in a project that uses Catalyst and DBIx::Class.
I have a requirement where, under a certain condition, users should not be able to read or set a specific field in a table (e.g. the last_name field in a list of users that will be presented and may be edited by the user).
Instead of applying the conditional logic to each part of the project where that table field is read or set, risking old or new cases where the logic is missed, is it possible to implement the logic directly in the DBIx::Class based module, to never return or change the value of that field when the condition is met?
I've been trying to find the answer, and I'm still reading, but I'm somewhat new to DBIx::Class and its documentation. Any help would be highly appreciated. Thank you!
I‘d use an around Moose method modifier on the column accessor generated by DBIC.
This won‘t be a real security solution as you can still access data without the Result class, for example when using HashRefInflator.
Same for calling get_column.
Real security would be at the database level with column level security and not allowing the database user used by the application to fetch that field.
Another solution I can think of is an additional Result class for that table that doesn‘t include the column, maybe even defaulting to it and only use the one including the column when the user has a special role.
This feels something like an archeology expedition but I have been unable to find the record format of the first record of seemingly all executable load modules on z/OS systems. The record always starts with IEWPLMH even with when producing a GOFF format (which I have) runnable. Does anyone have any information on this or a link to it?
The format of load modules is documented in the Load Module Formats section of the z/OS MVS Program Management: Advanced Facilities manual.
But I suspect you are looking for the format of a program object, which is not documented, and, last I knew, IBM had stated they would not document (at least publicly for the likes of us).
There are decades of history behind this. IBM found themselves painted into a corner because customers had written code that depended on the format of load modules not changing. As of 2011, there were 8 different formats/subformats of program object and that number has no doubt grown. By not documenting (for customers) the format of a program object, IBM felt they had freed themselves to make format changes (adding features customers wanted) as they saw fit.
You may be able to get the information you want using the Binder's API or AMBLIST.
The use of the IEWBINDD facility is definitely the way to go. For USS programs,
When compiling the source, the -Wc,DLL option is required. When linking the -Wl,DYNAM=DLL does the trick. The example program in the appendix of the z/OS MVS Program Management: Advanced Facilities was very helpful.
How to get column name and data type returned by a custom query in postgres? We have inbuilt functions for table/views but not for custom queries. For more clarification I would say that I need a postgres function which will take sql string as parameter and will return colnames and their datatype.
I don't think there's any built-in SQL function which does this for you.
If you want to do this purely at the SQL level, the simplest and cheapest way is probably to CREATE TEMP VIEW AS (<your_query>), dig the column definitions out of the catalog tables, and drop the view when you're done. However, this can have a non-trivial overhead depending on how often you do it (as it needs to write view definitions to the catalogs), can't be run in a read-only transaction, and can't be done on a standby server.
The ideal solution, if it fits your use case, is to build a prepared query on the client side, and make use of the metadata returned by the server (in the form of a RowDescription message passed as part of the query protocol). Unfortunately, this depends very much on which client library you're using, and how much of this information it chooses to expose. For example, libpq will give you access to everything, whereas the JDBC driver limits you to the public methods on its ResultSetMetadata object (though you could probably pull more information from its private fields via reflection, if you're determined enough).
If you want a read-only, low-overhead, client-independent solution, then you could also write a server-side C function to prepare and describe the query via SPI. Writing and building C functions comes with a bit of a learning curve, but you can find numerous examples on PGXN, or within Postgres' own contrib modules.
Why postgres have not given package like thing ,so that same type of function can be placed inside a individual collective unit . In current approach if postgres we have too write individual function that make to messy for origination of code.
There's a exhaustive discussion in PostgreSQL community about Oracle-style packages, as you can see here. I've been following this discussion from afar, IMHO there's a consensus that hackers should focus on more significant issues - related to Oracle to PostgreSQL migration - than packages.
In short, there's the need but it's at the end of the queue.
This subject has come up again and again since 2003. Every time the subject comes up, it is shot down in flames by the Postgres community. Suggesting using schema and name space is equivalent to packages shows the lack of understanding of what a package does. A package is not just simply a collection of procedures. An Oracle package provides public and private access to procedures and variables within the package. An instantiated package is essentially a self contained object.
There is Schema to classify function is needed.
If a schema name is included, then the function is created in the specified schema. Otherwise it is created in the current schema. The name of the new function must not match any existing function with the same input argument types in the same schema. However, functions of different argument types can share a name (this is called overloading).
I'm currently doing some maintenance on an application and I've come across a big issue regarding the qualified name in tsql. I wondering if someone could clear my confusion up for me.
From my understanding you want to use USE [DatabaseName] to declare which database you are using. I notice if u "rename" the databse it automatically updates these references in your code.
However, the developer who originally wrote this code used the USE [DatabaseName]. Then in later statements he wrote: SELECT * FROM [DatabaseName].[dbo].[Table]. Well this obviously breaks if I change the Database's name. From what i've read you want to qualify names only to the owner such as: [dbo].[TableName] so it knows where to look which increases performance.
Is there a reason he included the Database name in each statement?
From what i've read you want to qualify names only to the owner such as: [dbo].[TableName] so it knows where to look which increases performance.
Not that I'm aware of, rather it looks like someone is lazy.
I always use the three name format (unless accessing a linked server instance, then it's four).
The benefit is that the correct table from the correct database & schema will be used without concern for an errant USE [appropriate database] statement. As long as the object exists, and the permissions are valid based on the need, you can recreate a stored procedure, function, view, etc in other databases without needing to address the USE [appropriate database] statement each time.
But I'm working with data spread over numerous databases on the same instance. I wouldn't have necessarily designed it that way, but it wouldn't change that I use three (or four) part qualified name format.